Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
71009354
Commit
71009354
authored
May 11, 2002
by
Tom Lane
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update for additional options in CREATE OPERATOR.
parent
9b5ca7ee
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
74 additions
and
41 deletions
+74
-41
doc/src/sgml/xoper.sgml
doc/src/sgml/xoper.sgml
+74
-41
No files found.
doc/src/sgml/xoper.sgml
View file @
71009354
<!--
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.1
8 2002/03/22 19:20:34 petere
Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.1
9 2002/05/11 02:09:41 tgl
Exp $
-->
-->
<Chapter Id="xoper">
<Chapter Id="xoper">
...
@@ -322,10 +322,11 @@ table1.column1 OP table2.column2
...
@@ -322,10 +322,11 @@ table1.column1 OP table2.column2
<title>HASHES</title>
<title>HASHES</title>
<para>
<para>
The <literal>HASHES</literal> clause, if present, tells the system that it is OK to
The <literal>HASHES</literal> clause, if present, tells the system that
use the hash join method for a join based on this operator. <literal>HASHES</>
it is permissible to use the hash join method for a join based on this
only makes sense for binary operators that return <literal>boolean</>, and
operator. <literal>HASHES</> only makes sense for binary operators that
in practice the operator had better be equality for some data type.
return <literal>boolean</>, and in practice the operator had better be
equality for some data type.
</para>
</para>
<para>
<para>
...
@@ -377,80 +378,112 @@ table1.column1 OP table2.column2
...
@@ -377,80 +378,112 @@ table1.column1 OP table2.column2
</sect2>
</sect2>
<sect2>
<sect2>
<title>
SORT1 and SORT2
</title>
<title>
MERGES (SORT1, SORT2, LTCMP, GTCMP)
</title>
<para>
<para>
The <literal>SORT</literal> clauses, if present, tell the system that it is permissible to use
The <literal>MERGES</literal> clause, if present, tells the system that
the merge join method for a join based on the current operator.
it is permissible to use the merge join method for a join based on this
Both must be specified if either is. The current operator must be
operator. <literal>MERGES</> only makes sense for binary operators that
equality for some pair of data types, and the <literal>SORT1</> and <literal>SORT2</> clauses
return <literal>boolean</>, and in practice the operator must represent
name the ordering operator (<quote><</quote> operator) for the left and right-side
equality for some datatype or pair of datatypes.
data types respectively.
</para>
</para>
<para>
<para>
Merge join is based on the idea of sorting the left- and right-hand tables
Merge join is based on the idea of sorting the left- and right-hand tables
into order and then scanning them in parallel. So, both data types must
into order and then scanning them in parallel. So, both data types must
be capable of being fully ordered, and the join operator must be one
be capable of being fully ordered, and the join operator must be one
that can only succeed for pairs of values that fall at the <quote>same place</>
that can only succeed for pairs of values that fall at the
<quote>same place</>
in the sort order. In practice this means that the join operator must
in the sort order. In practice this means that the join operator must
behave like equality. But unlike hash join, where the left and right
behave like equality. But unlike hash join, where the left and right
data types had better be the same (or at least bitwise equivalent),
data types had better be the same (or at least bitwise equivalent),
it is possible to merge-join two
it is possible to merge-join two
distinct data types so long as they are logically compatible. For
distinct data types so long as they are logically compatible. For
example, the <type>int2</type>-versus-<type>int4</type> equality operator is merge-joinable.
example, the <type>int2</type>-versus-<type>int4</type> equality operator
is mergejoinable.
We only need sorting operators that will bring both data types into a
We only need sorting operators that will bring both data types into a
logically compatible sequence.
logically compatible sequence.
</para>
</para>
<para>
<para>
When specifying merge-sort operators, the current operator and both
Execution of a merge join requires that the system be able to identify
referenced operators must return <type>boolean</type>; the <literal>SORT1</> operator must have
four operators related to the mergejoin equality operator: less-than
both input data types equal to the current operator's left operand type,
comparison for the left input datatype, less-than comparison for the
and the <literal>SORT2</> operator must have
right input datatype, less-than comparison between the two datatypes, and
both input data types equal to the current operator's right operand type.
greater-than comparison between the two datatypes. (These are actually
(As with <literal>COMMUTATOR</> and <literal>NEGATOR</>, this means that the operator name is
four distinct operators if the mergejoinable operator has two different
sufficient to specify the operator, and the system is able to make dummy
input datatypes; but when the input types are the same the three
operator entries if you happen to define the equality operator before
less-than operators are all the same operator.)
the other ones.)
It is possible to
specify these operators individually by name, as the <literal>SORT1</>,
<literal>SORT2</>, <literal>LTCMP</>, and <literal>GTCMP</> options
respectively. The system will fill in the default names
<literal><</>, <literal><</>, <literal><</>, <literal>></>
respectively if any of these are omitted when <literal>MERGES</> is
specified. Also, <literal>MERGES</> will be assumed to be implied if any
of these four operator options appear, so it is possible to specify
just some of them and let the system fill in the rest.
</para>
</para>
<para>
<para>
In practice you should only write <literal>SORT</> clauses for an <literal>=</> operator,
The input datatypes of the four comparison operators can be deduced
and the two referenced operators should always be named <literal><</>. Trying
from the input types of the mergejoinable operator, so just as with
to use merge join with operators named anything else will result in
<literal>COMMUTATOR</>, only the operator names need be given in these
hopeless confusion, for reasons we'll see in a moment.
clauses. Unless you are using peculiar choices of operator names,
it's sufficient to write <literal>MERGES</> and let the system fill in
the details.
(As with <literal>COMMUTATOR</> and <literal>NEGATOR</>, the system is
able to make dummy
operator entries if you happen to define the equality operator before
the other ones.)
</para>
</para>
<para>
<para>
There are additional restrictions on operators that you mark
There are additional restrictions on operators that you mark
merge
-
joinable. These restrictions are not currently checked by
mergejoinable. These restrictions are not currently checked by
<command>CREATE OPERATOR</command>, but
a merge join may fail at run time if any are
<command>CREATE OPERATOR</command>, but
errors may occur when
not true:
the operator is used if any are
not true:
<itemizedlist>
<itemizedlist>
<listitem>
<listitem>
<para>
<para>
The merge-joinable equality operator must have a commutator
A mergejoinable equality operator must have a mergejoinable
(itself if the two data types are the same, or a related equality operator
commutator (itself if the two data types are the same, or a related
if they are different).
equality operator
if they are different).
</para>
</para>
</listitem>
</listitem>
<listitem>
<listitem>
<para>
<para>
There must be <literal><</> and <literal>></> ordering operators having the same left and
If there is a mergejoinable operator relating any two data types
right operand data types as the merge-joinable operator itself. These
A and B, and another mergejoinable operator relating B to any
operators <emphasis>must</emphasis> be named <literal><</> and <literal>></>; you do
third data type C, then A and C must also have a mergejoinable
not have any choice in the matter, since there is no provision for
operator; in other words, having a mergejoinable operator must
specifying them explicitly. Note that if the left and right data types
be transitive.
are different, neither of these operators is the same as either
</para>
<literal>SORT</literal> operator. But they had better order the data values compatibly
</listitem>
with the <literal>SORT</literal> operators, or the merge join will fail to work.
<listitem>
<para>
Bizarre results will ensue at runtime if the four comparison
operators you name do not sort the data values compatibly.
</para>
</para>
</listitem>
</listitem>
</itemizedlist>
</itemizedlist>
</para>
</para>
<note>
<para>
In <ProductName>PostgreSQL</ProductName> versions before 7.3,
the <literal>MERGES</> shorthand was not available: to make a
mergejoinable operator one had to write both <literal>SORT1</> and
<literal>SORT2</> explicitly. Also, the <literal>LTCMP</> and
<literal>GTCMP</>
options did not exist; the names of those operators were hardwired as
<literal><</> and <literal>></> respectively.
</para>
</note>
</sect2>
</sect2>
</sect1>
</sect1>
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment