Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitf41803b

Browse files
committed
Refactor planner's pathkeys data structure to create a separate, explicit
representation of equivalence classes of variables. This is an extensiverewrite, but it brings a number of benefits:* planner no longer fails in the presence of "incomplete" operator familiesthat don't offer operators for every possible combination of datatypes.* avoid generating and then discarding redundant equality clauses.* remove bogus assumption that derived equalities always use operatorsnamed "=".* mergejoins can work with a variety of sort orders (e.g., descending) now,instead of tying each mergejoinable operator to exactly one sort order.* better recognition of redundant sort columns.* can make use of equalities appearing underneath an outer join.
1 parent2b7334d commitf41803b

35 files changed

+3860
-2697
lines changed

‎doc/src/sgml/xoper.sgml‎

Lines changed: 38 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.37 2006/12/23 00:43:08 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.38 2007/01/20 20:45:38 tgl Exp $ -->
22

33
<sect1 id="xoper">
44
<title>User-Defined Operators</title>
@@ -145,29 +145,29 @@ SELECT (a + b) AS c FROM test_complex;
145145
<itemizedlist>
146146
<listitem>
147147
<para>
148-
One way is to omit the <literal>COMMUTATOR</> clause in the first operator that
149-
you define, and then provide one in the second operator's definition.
150-
Since <productname>PostgreSQL</productname> knows that commutative
151-
operators come in pairs, when it sees the second definition it will
152-
automatically go back and fill in the missing <literal>COMMUTATOR</> clause in
153-
the first definition.
148+
One way is to omit the <literal>COMMUTATOR</> clause in the first operator that
149+
you define, and then provide one in the second operator's definition.
150+
Since <productname>PostgreSQL</productname> knows that commutative
151+
operators come in pairs, when it sees the second definition it will
152+
automatically go back and fill in the missing <literal>COMMUTATOR</> clause in
153+
the first definition.
154154
</para>
155155
</listitem>
156156

157157
<listitem>
158158
<para>
159-
The other, more straightforward way is just to include <literal>COMMUTATOR</> clauses
160-
in both definitions. When <productname>PostgreSQL</productname> processes
161-
the first definition and realizes that <literal>COMMUTATOR</> refers to a nonexistent
162-
operator, the system will make a dummy entry for that operator in the
163-
system catalog. This dummy entry will have valid data only
164-
for the operator name, left and right operand types, and result type,
165-
since that's all that <productname>PostgreSQL</productname> can deduce
166-
at this point. The first operator's catalog entry will link to this
167-
dummy entry. Later, when you define the second operator, the system
168-
updates the dummy entry with the additional information from the second
169-
definition. If you try to use the dummy operator before it's been filled
170-
in, you'll just get an error message.
159+
The other, more straightforward way is just to include <literal>COMMUTATOR</> clauses
160+
in both definitions. When <productname>PostgreSQL</productname> processes
161+
the first definition and realizes that <literal>COMMUTATOR</> refers to a nonexistent
162+
operator, the system will make a dummy entry for that operator in the
163+
system catalog. This dummy entry will have valid data only
164+
for the operator name, left and right operand types, and result type,
165+
since that's all that <productname>PostgreSQL</productname> can deduce
166+
at this point. The first operator's catalog entry will link to this
167+
dummy entry. Later, when you define the second operator, the system
168+
updates the dummy entry with the additional information from the second
169+
definition. If you try to use the dummy operator before it's been filled
170+
in, you'll just get an error message.
171171
</para>
172172
</listitem>
173173
</itemizedlist>
@@ -240,7 +240,7 @@ column OP constant
240240
one of the system's standard estimators for many of your own operators.
241241
These are the standard restriction estimators:
242242
<simplelist>
243-
<member><function>eqsel</>for <literal>=</></member>
243+
<member><function>eqsel</>for <literal>=</></member>
244244
<member><function>neqsel</> for <literal>&lt;&gt;</></member>
245245
<member><function>scalarltsel</> for <literal>&lt;</> or <literal>&lt;=</></member>
246246
<member><function>scalargtsel</> for <literal>&gt;</> or <literal>&gt;=</></member>
@@ -337,7 +337,7 @@ table1.column1 OP table2.column2
337337
join will never compare them at all, implicitly assuming that the
338338
result of the join operator must be false. So it never makes sense
339339
to specify <literal>HASHES</literal> for operators that do not represent
340-
equality.
340+
some form ofequality.
341341
</para>
342342

343343
<para>
@@ -347,7 +347,7 @@ table1.column1 OP table2.column2
347347
exist yet. But attempts to use the operator in hash joins will fail
348348
at run time if no such operator family exists. The system needs the
349349
operator family to find the data-type-specific hash function for the
350-
operator's input data type. Of course, you must alsosupply a suitable
350+
operator's input data type. Of course, you must alsocreate a suitable
351351
hash function before you can create the operator family.
352352
</para>
353353

@@ -382,8 +382,9 @@ table1.column1 OP table2.column2
382382
false, never null, for any two nonnull inputs. If this rule is
383383
not followed, hash-optimization of <literal>IN</> operations may
384384
generate wrong results. (Specifically, <literal>IN</> might return
385-
false where the correct answer according to the standard would be null; or it might
386-
yield an error complaining that it wasn't prepared for a null result.)
385+
false where the correct answer according to the standard would be null;
386+
or it might yield an error complaining that it wasn't prepared for a
387+
null result.)
387388
</para>
388389
</note>
389390

@@ -407,19 +408,18 @@ table1.column1 OP table2.column2
407408
that can only succeed for pairs of values that fall at the
408409
<quote>same place</>
409410
in the sort order. In practice this means that the join operator must
410-
behave like equality. But unlike hash join, where the left and right
411-
data types had better be the same (or at least bitwise equivalent),
412-
it is possible to merge-join two
411+
behave like equality. But it is possible to merge-join two
413412
distinct data types so long as they are logically compatible. For
414-
example, the <type>smallint</type>-versus-<type>integer</type> equality operator
415-
is merge-joinable.
413+
example, the <type>smallint</type>-versus-<type>integer</type>
414+
equality operatoris merge-joinable.
416415
We only need sorting operators that will bring both data types into a
417416
logically compatible sequence.
418417
</para>
419418

420419
<para>
421420
To be marked <literal>MERGES</literal>, the join operator must appear
422-
in a btree index operator family. This is not enforced when you create
421+
as an equality member of a btree index operator family.
422+
This is not enforced when you create
423423
the operator, since of course the referencing operator family couldn't
424424
exist yet. But the operator will not actually be used for merge joins
425425
unless a matching operator family can be found. The
@@ -428,30 +428,14 @@ table1.column1 OP table2.column2
428428
</para>
429429

430430
<para>
431-
There are additional restrictions on operators that you mark
432-
merge-joinable. These restrictions are not currently checked by
433-
<command>CREATE OPERATOR</command>, but errors may occur when
434-
the operator is used if any are not true:
435-
436-
<itemizedlist>
437-
<listitem>
438-
<para>
439-
A merge-joinable equality operator must have a merge-joinable
440-
commutator (itself if the two operand data types are the same, or a related
441-
equality operator if they are different).
442-
</para>
443-
</listitem>
444-
445-
<listitem>
446-
<para>
447-
If there is a merge-joinable operator relating any two data types
448-
A and B, and another merge-joinable operator relating B to any
449-
third data type C, then A and C must also have a merge-joinable
450-
operator; in other words, having a merge-joinable operator must
451-
be transitive.
452-
</para>
453-
</listitem>
454-
</itemizedlist>
431+
A merge-joinable operator must have a commutator (itself if the two
432+
operand data types are the same, or a related equality operator
433+
if they are different) that appears in the same operator family.
434+
If this is not the case, planner errors may occur when the operator
435+
is used. Also, it is a good idea (but not strictly required) for
436+
a btree operator family that supports multiple datatypes to provide
437+
equality operators for every combination of the datatypes; this
438+
allows better optimization.
455439
</para>
456440

457441
<note>

‎src/backend/nodes/copyfuncs.c‎

Lines changed: 19 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@
1515
* Portions Copyright (c) 1994, Regents of the University of California
1616
*
1717
* IDENTIFICATION
18-
* $PostgreSQL: pgsql/src/backend/nodes/copyfuncs.c,v 1.361 2007/01/10 18:06:02 tgl Exp $
18+
* $PostgreSQL: pgsql/src/backend/nodes/copyfuncs.c,v 1.362 2007/01/20 20:45:38 tgl Exp $
1919
*
2020
*-------------------------------------------------------------------------
2121
*/
@@ -1284,16 +1284,18 @@ _copyFromExpr(FromExpr *from)
12841284
*/
12851285

12861286
/*
1287-
*_copyPathKeyItem
1287+
*_copyPathKey
12881288
*/
1289-
staticPathKeyItem*
1290-
_copyPathKeyItem(PathKeyItem*from)
1289+
staticPathKey*
1290+
_copyPathKey(PathKey*from)
12911291
{
1292-
PathKeyItem*newnode=makeNode(PathKeyItem);
1292+
PathKey*newnode=makeNode(PathKey);
12931293

1294-
COPY_NODE_FIELD(key);
1295-
COPY_SCALAR_FIELD(sortop);
1296-
COPY_SCALAR_FIELD(nulls_first);
1294+
/* EquivalenceClasses are never moved, so just shallow-copy the pointer */
1295+
COPY_SCALAR_FIELD(pk_eclass);
1296+
COPY_SCALAR_FIELD(pk_opfamily);
1297+
COPY_SCALAR_FIELD(pk_strategy);
1298+
COPY_SCALAR_FIELD(pk_nulls_first);
12971299

12981300
returnnewnode;
12991301
}
@@ -1316,21 +1318,15 @@ _copyRestrictInfo(RestrictInfo *from)
13161318
COPY_BITMAPSET_FIELD(left_relids);
13171319
COPY_BITMAPSET_FIELD(right_relids);
13181320
COPY_NODE_FIELD(orclause);
1321+
/* EquivalenceClasses are never copied, so shallow-copy the pointers */
1322+
COPY_SCALAR_FIELD(parent_ec);
13191323
COPY_SCALAR_FIELD(eval_cost);
13201324
COPY_SCALAR_FIELD(this_selec);
1321-
COPY_SCALAR_FIELD(mergejoinoperator);
1322-
COPY_SCALAR_FIELD(left_sortop);
1323-
COPY_SCALAR_FIELD(right_sortop);
1324-
COPY_SCALAR_FIELD(mergeopfamily);
1325-
1326-
/*
1327-
* Do not copy pathkeys, since they'd not be canonical in a copied query
1328-
*/
1329-
newnode->left_pathkey=NIL;
1330-
newnode->right_pathkey=NIL;
1331-
1332-
COPY_SCALAR_FIELD(left_mergescansel);
1333-
COPY_SCALAR_FIELD(right_mergescansel);
1325+
COPY_NODE_FIELD(mergeopfamilies);
1326+
/* EquivalenceClasses are never copied, so shallow-copy the pointers */
1327+
COPY_SCALAR_FIELD(left_ec);
1328+
COPY_SCALAR_FIELD(right_ec);
1329+
COPY_SCALAR_FIELD(outer_is_left);
13341330
COPY_SCALAR_FIELD(hashjoinoperator);
13351331
COPY_SCALAR_FIELD(left_bucketsize);
13361332
COPY_SCALAR_FIELD(right_bucketsize);
@@ -3033,8 +3029,8 @@ copyObject(void *from)
30333029
/*
30343030
* RELATION NODES
30353031
*/
3036-
caseT_PathKeyItem:
3037-
retval=_copyPathKeyItem(from);
3032+
caseT_PathKey:
3033+
retval=_copyPathKey(from);
30383034
break;
30393035
caseT_RestrictInfo:
30403036
retval=_copyRestrictInfo(from);

‎src/backend/nodes/equalfuncs.c‎

Lines changed: 23 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@
1818
* Portions Copyright (c) 1994, Regents of the University of California
1919
*
2020
* IDENTIFICATION
21-
* $PostgreSQL: pgsql/src/backend/nodes/equalfuncs.c,v 1.295 2007/01/10 18:06:03 tgl Exp $
21+
* $PostgreSQL: pgsql/src/backend/nodes/equalfuncs.c,v 1.296 2007/01/20 20:45:38 tgl Exp $
2222
*
2323
*-------------------------------------------------------------------------
2424
*/
@@ -596,11 +596,27 @@ _equalFromExpr(FromExpr *a, FromExpr *b)
596596
*/
597597

598598
staticbool
599-
_equalPathKeyItem(PathKeyItem*a,PathKeyItem*b)
599+
_equalPathKey(PathKey*a,PathKey*b)
600600
{
601-
COMPARE_NODE_FIELD(key);
602-
COMPARE_SCALAR_FIELD(sortop);
603-
COMPARE_SCALAR_FIELD(nulls_first);
601+
/*
602+
* This is normally used on non-canonicalized PathKeys, so must chase
603+
* up to the topmost merged EquivalenceClass and see if those are the
604+
* same (by pointer equality).
605+
*/
606+
EquivalenceClass*a_eclass;
607+
EquivalenceClass*b_eclass;
608+
609+
a_eclass=a->pk_eclass;
610+
while (a_eclass->ec_merged)
611+
a_eclass=a_eclass->ec_merged;
612+
b_eclass=b->pk_eclass;
613+
while (b_eclass->ec_merged)
614+
b_eclass=b_eclass->ec_merged;
615+
if (a_eclass!=b_eclass)
616+
return false;
617+
COMPARE_SCALAR_FIELD(pk_opfamily);
618+
COMPARE_SCALAR_FIELD(pk_strategy);
619+
COMPARE_SCALAR_FIELD(pk_nulls_first);
604620

605621
return true;
606622
}
@@ -2016,8 +2032,8 @@ equal(void *a, void *b)
20162032
/*
20172033
* RELATION NODES
20182034
*/
2019-
caseT_PathKeyItem:
2020-
retval=_equalPathKeyItem(a,b);
2035+
caseT_PathKey:
2036+
retval=_equalPathKey(a,b);
20212037
break;
20222038
caseT_RestrictInfo:
20232039
retval=_equalRestrictInfo(a,b);

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp