aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeNestloop.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2008-08-15 19:20:42 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2008-08-15 19:20:42 +0000
commit118461114e14f4fac5103df173df192771b5befc (patch)
tree5fa7ffade872a081f8133e119c7255306d6f37f1 /src/backend/executor/nodeNestloop.c
parent5b8eb2b4b95ac4b016368ce6ca2c3477387e7fc7 (diff)
downloadpostgresql-118461114e14f4fac5103df173df192771b5befc.tar.gz
postgresql-118461114e14f4fac5103df173df192771b5befc.zip
Performance fix for new anti-join code in nodeMergejoin.c: after finding a
match in antijoin mode, we should advance to next outer tuple not next inner. We know we don't want to return this outer tuple, and there is no point in advancing over matching inner tuples now, because we'd just have to do it again if the next outer tuple has the same merge key. This makes a noticeable difference if there are lots of duplicate keys in both inputs. Similarly, after finding a match in semijoin mode, arrange to advance to the next outer tuple after returning the current match; or immediately, if it fails the extra quals. The rationale is the same. (This is a performance bug in existing releases; perhaps worth back-patching? The planner tries to avoid using mergejoin with lots of duplicates, so it may not be a big issue in practice.) Nestloop and hash got this right to start with, but I made some cosmetic adjustments there to make the corresponding bits of logic look more similar.
Diffstat (limited to 'src/backend/executor/nodeNestloop.c')
-rw-r--r--src/backend/executor/nodeNestloop.c47
1 files changed, 24 insertions, 23 deletions
diff --git a/src/backend/executor/nodeNestloop.c b/src/backend/executor/nodeNestloop.c
index c6a33228582..27e3582649e 100644
--- a/src/backend/executor/nodeNestloop.c
+++ b/src/backend/executor/nodeNestloop.c
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/executor/nodeNestloop.c,v 1.47 2008/08/14 18:47:58 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/executor/nodeNestloop.c,v 1.48 2008/08/15 19:20:42 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -226,35 +226,36 @@ ExecNestLoop(NestLoopState *node)
/* In an antijoin, we never return a matched tuple */
if (node->js.jointype == JOIN_ANTI)
+ {
node->nl_NeedNewOuter = true;
- else
+ continue; /* return to top of loop */
+ }
+
+ /*
+ * In a semijoin, we'll consider returning the first match,
+ * but after that we're done with this outer tuple.
+ */
+ if (node->js.jointype == JOIN_SEMI)
+ node->nl_NeedNewOuter = true;
+
+ if (otherqual == NIL || ExecQual(otherqual, econtext, false))
{
/*
- * In a semijoin, we'll consider returning the first match,
- * but after that we're done with this outer tuple.
+ * qualification was satisfied so we project and return the
+ * slot containing the result tuple using ExecProject().
*/
- if (node->js.jointype == JOIN_SEMI)
- node->nl_NeedNewOuter = true;
- if (otherqual == NIL || ExecQual(otherqual, econtext, false))
- {
- /*
- * qualification was satisfied so we project and return
- * the slot containing the result tuple using
- * ExecProject().
- */
- TupleTableSlot *result;
- ExprDoneCond isDone;
+ TupleTableSlot *result;
+ ExprDoneCond isDone;
- ENL1_printf("qualification succeeded, projecting tuple");
+ ENL1_printf("qualification succeeded, projecting tuple");
- result = ExecProject(node->js.ps.ps_ProjInfo, &isDone);
+ result = ExecProject(node->js.ps.ps_ProjInfo, &isDone);
- if (isDone != ExprEndResult)
- {
- node->js.ps.ps_TupFromTlist =
- (isDone == ExprMultipleResult);
- return result;
- }
+ if (isDone != ExprEndResult)
+ {
+ node->js.ps.ps_TupFromTlist =
+ (isDone == ExprMultipleResult);
+ return result;
}
}
}