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

Commit07b9936

Browse files
committed
Temporarily (I hope) disable flattening of IN/EXISTS sublinks that are within
the ON clause of an outer join. Doing so is semantically correct but resultsin de-optimizing queries that were structured to take advantage of the sublinkstyle of execution, as seen in recent complaint from Kevin Grittner. Sincethe user can get the other behavior by reorganizing his query, having theflattening happen automatically is just a convenience, and that doesn'tjustify breaking existing applications. Eventually it would be nice tore-enable this, but that seems to require a significantly different approachto outer joins in the executor.
1 parent75c85bd commit07b9936

File tree

1 file changed

+14
-1
lines changed

1 file changed

+14
-1
lines changed

‎src/backend/optimizer/prep/prepjointree.c

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@
1616
*
1717
*
1818
* IDENTIFICATION
19-
* $PostgreSQL: pgsql/src/backend/optimizer/prep/prepjointree.c,v 1.63 2009/02/25 03:30:37 tgl Exp $
19+
* $PostgreSQL: pgsql/src/backend/optimizer/prep/prepjointree.c,v 1.64 2009/02/27 23:30:29 tgl Exp $
2020
*
2121
*-------------------------------------------------------------------------
2222
*/
@@ -220,6 +220,15 @@ pull_up_sublinks_jointree_recurse(PlannerInfo *root, Node *jtnode,
220220
* The point of the available_rels machinations is to ensure that we
221221
* only pull up quals for which that's okay.
222222
*
223+
* XXX for the moment, we refrain from pulling up IN/EXISTS clauses
224+
* appearing in LEFT or RIGHT join conditions. Although it is
225+
* semantically valid to do so under the above conditions, we end up
226+
* with a query in which the semijoin or antijoin must be evaluated
227+
* below the outer join, which could perform far worse than leaving
228+
* it as a sublink that is executed only for row pairs that meet the
229+
* other join conditions. Fixing this seems to require considerable
230+
* restructuring of the executor, but maybe someday it can happen.
231+
*
223232
* We don't expect to see any pre-existing JOIN_SEMI or JOIN_ANTI
224233
* nodes here.
225234
*/
@@ -232,17 +241,21 @@ pull_up_sublinks_jointree_recurse(PlannerInfo *root, Node *jtnode,
232241
&jtlink);
233242
break;
234243
caseJOIN_LEFT:
244+
#ifdefNOT_USED/* see XXX comment above */
235245
j->quals=pull_up_sublinks_qual_recurse(root,j->quals,
236246
rightrelids,
237247
&j->rarg);
248+
#endif
238249
break;
239250
caseJOIN_FULL:
240251
/* can't do anything with full-join quals */
241252
break;
242253
caseJOIN_RIGHT:
254+
#ifdefNOT_USED/* see XXX comment above */
243255
j->quals=pull_up_sublinks_qual_recurse(root,j->quals,
244256
leftrelids,
245257
&j->larg);
258+
#endif
246259
break;
247260
default:
248261
elog(ERROR,"unrecognized join type: %d",

0 commit comments

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