Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 07b9936

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 results in de-optimizing queries that were structured to take advantage of the sublink style of execution, as seen in recent complaint from Kevin Grittner. Since the user can get the other behavior by reorganizing his query, having the flattening happen automatically is just a convenience, and that doesn't justify breaking existing applications. Eventually it would be nice to re-enable this, but that seems to require a significantly different approach to outer joins in the executor.
1 parent 75c85bd commit 07b9936

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
case JOIN_LEFT:
244+
#ifdef NOT_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
case JOIN_FULL:
240251
/* can't do anything with full-join quals */
241252
break;
242253
case JOIN_RIGHT:
254+
#ifdef NOT_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)