Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
71009354
Commit
71009354
authored
22 years ago
by
Tom Lane
Browse files
Options
Downloads
Patches
Plain Diff
Update for additional options in CREATE OPERATOR.
parent
9b5ca7ee
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/src/sgml/xoper.sgml
+74
-41
74 additions, 41 deletions
doc/src/sgml/xoper.sgml
with
74 additions
and
41 deletions
doc/src/sgml/xoper.sgml
+
74
−
41
View file @
71009354
<!--
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.1
8
2002/0
3/22 19:20:34 petere
Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.1
9
2002/0
5/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>
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment