1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* nodeNestloop.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* routines to support nest-loop joins
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/executor/nodeNestloop.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* INTERFACE ROUTINES
|
|
|
|
* ExecNestLoop - process a nestloop join of two plans
|
|
|
|
* ExecInitNestLoop - initialize the join
|
|
|
|
* ExecEndNestLoop - shut down the join
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-17 05:05:41 +02:00
|
|
|
|
1996-10-31 11:12:26 +01:00
|
|
|
#include "postgres.h"
|
|
|
|
|
1996-11-08 07:02:30 +01:00
|
|
|
#include "executor/execdebug.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "executor/nodeNestloop.h"
|
2017-07-26 02:37:17 +02:00
|
|
|
#include "miscadmin.h"
|
2000-07-17 05:05:41 +02:00
|
|
|
#include "utils/memutils.h"
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecNestLoop(node)
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* old comments
|
1997-09-07 07:04:48 +02:00
|
|
|
* Returns the tuple joined from inner and outer tuples which
|
|
|
|
* satisfies the qualification clause.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* It scans the inner relation to join with current outer tuple.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-07-12 04:37:39 +02:00
|
|
|
* If none is found, next tuple from the outer relation is retrieved
|
1997-09-07 07:04:48 +02:00
|
|
|
* and the inner relation is scanned from the beginning again to join
|
|
|
|
* with the outer tuple.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-07-12 04:37:39 +02:00
|
|
|
* NULL is returned if all the remaining outer tuples are tried and
|
1997-09-07 07:04:48 +02:00
|
|
|
* all fail to join with the inner tuples.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-07-12 04:37:39 +02:00
|
|
|
* NULL is also returned if there is no tuple from inner relation.
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
|
|
|
* Conditions:
|
|
|
|
* -- outerTuple contains current tuple from outer relation and
|
2000-07-12 04:37:39 +02:00
|
|
|
* the right son(inner relation) maintains "cursor" at the tuple
|
1997-09-07 07:04:48 +02:00
|
|
|
* returned previously.
|
|
|
|
* This is achieved by maintaining a scan position on the outer
|
|
|
|
* relation.
|
|
|
|
*
|
|
|
|
* Initial States:
|
|
|
|
* -- the outer child and the inner child
|
|
|
|
* are prepared to return the first tuple.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
2017-07-17 09:33:49 +02:00
|
|
|
static TupleTableSlot *
|
|
|
|
ExecNestLoop(PlanState *pstate)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2017-07-17 09:33:49 +02:00
|
|
|
NestLoopState *node = castNode(NestLoopState, pstate);
|
2010-07-12 19:01:06 +02:00
|
|
|
NestLoop *nl;
|
2002-12-05 16:50:39 +01:00
|
|
|
PlanState *innerPlan;
|
|
|
|
PlanState *outerPlan;
|
1997-09-07 07:04:48 +02:00
|
|
|
TupleTableSlot *outerTupleSlot;
|
|
|
|
TupleTableSlot *innerTupleSlot;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExprState *joinqual;
|
|
|
|
ExprState *otherqual;
|
1997-09-08 04:41:22 +02:00
|
|
|
ExprContext *econtext;
|
2010-07-12 19:01:06 +02:00
|
|
|
ListCell *lc;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2017-07-26 02:37:17 +02:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* get information from the node
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
ENL1_printf("getting info from node");
|
|
|
|
|
2010-07-12 19:01:06 +02:00
|
|
|
nl = (NestLoop *) node->js.ps.plan;
|
2002-12-05 16:50:39 +01:00
|
|
|
joinqual = node->js.joinqual;
|
|
|
|
otherqual = node->js.ps.qual;
|
|
|
|
outerPlan = outerPlanState(node);
|
|
|
|
innerPlan = innerPlanState(node);
|
|
|
|
econtext = node->js.ps.ps_ExprContext;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* Reset per-tuple memory context to free any expression evaluation
|
2017-01-19 23:12:38 +01:00
|
|
|
* storage allocated in the previous tuple cycle.
|
2000-08-24 05:29:15 +02:00
|
|
|
*/
|
|
|
|
ResetExprContext(econtext);
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* Ok, everything is setup for the join so now loop until we return a
|
|
|
|
* qualifying join tuple.
|
2000-07-12 04:37:39 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
ENL1_printf("entering main loop");
|
2000-07-12 04:37:39 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (;;)
|
|
|
|
{
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* If we don't have an outer tuple, get the next one and reset the
|
|
|
|
* inner scan.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-12-05 16:50:39 +01:00
|
|
|
if (node->nl_NeedNewOuter)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
ENL1_printf("getting new outer tuple");
|
2002-12-05 16:50:39 +01:00
|
|
|
outerTupleSlot = ExecProcNode(outerPlan);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* if there are no more outer tuples, then the join is complete..
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
if (TupIsNull(outerTupleSlot))
|
|
|
|
{
|
|
|
|
ENL1_printf("no outer tuple, ending join");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ENL1_printf("saving new outer tuple information");
|
2000-09-12 23:07:18 +02:00
|
|
|
econtext->ecxt_outertuple = outerTupleSlot;
|
2002-12-05 16:50:39 +01:00
|
|
|
node->nl_NeedNewOuter = false;
|
|
|
|
node->nl_MatchedOuter = false;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* fetch the values of any outer Vars that must be passed to the
|
|
|
|
* inner scan, and store them in the appropriate PARAM_EXEC slots.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2010-07-12 19:01:06 +02:00
|
|
|
foreach(lc, nl->nestParams)
|
|
|
|
{
|
|
|
|
NestLoopParam *nlp = (NestLoopParam *) lfirst(lc);
|
|
|
|
int paramno = nlp->paramno;
|
|
|
|
ParamExecData *prm;
|
|
|
|
|
|
|
|
prm = &(econtext->ecxt_param_exec_vals[paramno]);
|
2011-10-11 20:20:06 +02:00
|
|
|
/* Param value should be an OUTER_VAR var */
|
2011-11-03 05:50:58 +01:00
|
|
|
Assert(IsA(nlp->paramval, Var));
|
2011-10-11 20:20:06 +02:00
|
|
|
Assert(nlp->paramval->varno == OUTER_VAR);
|
2010-07-12 19:01:06 +02:00
|
|
|
Assert(nlp->paramval->varattno > 0);
|
|
|
|
prm->value = slot_getattr(outerTupleSlot,
|
|
|
|
nlp->paramval->varattno,
|
|
|
|
&(prm->isnull));
|
|
|
|
/* Flag parameter value as changed */
|
|
|
|
innerPlan->chgParam = bms_add_member(innerPlan->chgParam,
|
|
|
|
paramno);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2010-07-12 19:01:06 +02:00
|
|
|
* now rescan the inner plan
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2010-07-12 19:01:06 +02:00
|
|
|
ENL1_printf("rescanning inner plan");
|
|
|
|
ExecReScan(innerPlan);
|
2000-09-12 23:07:18 +02:00
|
|
|
}
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* we have an outerTuple, try to get the next inner tuple.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
|
|
|
ENL1_printf("getting new inner tuple");
|
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
innerTupleSlot = ExecProcNode(innerPlan);
|
2000-09-12 23:07:18 +02:00
|
|
|
econtext->ecxt_innertuple = innerTupleSlot;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
if (TupIsNull(innerTupleSlot))
|
|
|
|
{
|
|
|
|
ENL1_printf("no inner tuple, need new outer tuple");
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
node->nl_NeedNewOuter = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
if (!node->nl_MatchedOuter &&
|
2008-08-14 20:48:00 +02:00
|
|
|
(node->js.jointype == JOIN_LEFT ||
|
|
|
|
node->js.jointype == JOIN_ANTI))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We are doing an outer join and there were no join matches
|
|
|
|
* for this outer tuple. Generate a fake join tuple with
|
|
|
|
* nulls for the inner tuple, and return it if it passes the
|
|
|
|
* non-join quals.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
2002-12-05 16:50:39 +01:00
|
|
|
econtext->ecxt_innertuple = node->nl_NullInnerTupleSlot;
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
ENL1_printf("testing qualification for outer-join tuple");
|
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (otherqual == NULL || ExecQual(otherqual, econtext))
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* qualification was satisfied so we project and return
|
|
|
|
* the slot containing the result tuple using
|
2001-03-22 07:16:21 +01:00
|
|
|
* ExecProject().
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
|
|
|
ENL1_printf("qualification succeeded, projecting tuple");
|
|
|
|
|
2017-01-19 23:12:38 +01:00
|
|
|
return ExecProject(node->js.ps.ps_ProjInfo);
|
2000-09-12 23:07:18 +02:00
|
|
|
}
|
2011-09-22 17:29:18 +02:00
|
|
|
else
|
|
|
|
InstrCountFiltered2(node, 1);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
/*
|
|
|
|
* Otherwise just return to top of loop for a new outer tuple.
|
|
|
|
*/
|
|
|
|
continue;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* at this point we have a new pair of inner and outer tuples so we
|
|
|
|
* test the inner and outer tuples to see if they satisfy the node's
|
|
|
|
* qualification.
|
2000-09-12 23:07:18 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* Only the joinquals determine MatchedOuter status, but all quals
|
|
|
|
* must pass to actually return the tuple.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
ENL1_printf("testing qualification");
|
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (ExecQual(joinqual, econtext))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2002-12-05 16:50:39 +01:00
|
|
|
node->nl_MatchedOuter = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2008-08-14 20:48:00 +02:00
|
|
|
/* In an antijoin, we never return a matched tuple */
|
|
|
|
if (node->js.jointype == JOIN_ANTI)
|
2008-08-15 21:20:42 +02:00
|
|
|
{
|
2008-08-14 20:48:00 +02:00
|
|
|
node->nl_NeedNewOuter = true;
|
2008-08-15 21:20:42 +02:00
|
|
|
continue; /* return to top of loop */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-04-08 04:20:03 +02:00
|
|
|
* If we only need to join to the first matching inner tuple, then
|
|
|
|
* consider returning this one, but after that continue with next
|
|
|
|
* outer tuple.
|
2008-08-15 21:20:42 +02:00
|
|
|
*/
|
2017-04-08 04:20:03 +02:00
|
|
|
if (node->js.single_match)
|
2008-08-15 21:20:42 +02:00
|
|
|
node->nl_NeedNewOuter = true;
|
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (otherqual == NULL || ExecQual(otherqual, econtext))
|
2000-08-24 05:29:15 +02:00
|
|
|
{
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2008-08-15 21:20:42 +02:00
|
|
|
* qualification was satisfied so we project and return the
|
|
|
|
* slot containing the result tuple using ExecProject().
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
2008-08-15 21:20:42 +02:00
|
|
|
ENL1_printf("qualification succeeded, projecting tuple");
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2017-01-19 23:12:38 +01:00
|
|
|
return ExecProject(node->js.ps.ps_ProjInfo);
|
2000-08-24 05:29:15 +02:00
|
|
|
}
|
2011-09-22 17:29:18 +02:00
|
|
|
else
|
|
|
|
InstrCountFiltered2(node, 1);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2011-09-22 17:29:18 +02:00
|
|
|
else
|
|
|
|
InstrCountFiltered1(node, 1);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* Tuple fails qual, so free per-tuple memory and try again.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-07-12 04:37:39 +02:00
|
|
|
ResetExprContext(econtext);
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
ENL1_printf("qualification failed, looping");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecInitNestLoop
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
2002-12-05 16:50:39 +01:00
|
|
|
NestLoopState *
|
2006-02-28 05:10:28 +01:00
|
|
|
ExecInitNestLoop(NestLoop *node, EState *estate, int eflags)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
NestLoopState *nlstate;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2006-02-28 05:10:28 +01:00
|
|
|
/* check for unsupported flags */
|
|
|
|
Assert(!(eflags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)));
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
NL1_printf("ExecInitNestLoop: %s\n",
|
|
|
|
"initializing node");
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-12-05 16:50:39 +01:00
|
|
|
* create state structure
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
nlstate = makeNode(NestLoopState);
|
2002-12-05 16:50:39 +01:00
|
|
|
nlstate->js.ps.plan = (Plan *) node;
|
|
|
|
nlstate->js.ps.state = estate;
|
2017-07-17 09:33:49 +02:00
|
|
|
nlstate->js.ps.ExecProcNode = ExecNestLoop;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* Miscellaneous initialization
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2001-03-22 07:16:21 +01:00
|
|
|
* create expression context for node
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-12-05 16:50:39 +01:00
|
|
|
ExecAssignExprContext(estate, &nlstate->js.ps);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
/*
|
|
|
|
* initialize child nodes
|
2006-02-28 05:10:28 +01:00
|
|
|
*
|
2010-07-12 19:01:06 +02:00
|
|
|
* If we have no parameters to pass into the inner rel from the outer,
|
|
|
|
* tell the inner child that cheap rescans would be good. If we do have
|
2011-04-10 17:42:00 +02:00
|
|
|
* such parameters, then there is no point in REWIND support at all in the
|
|
|
|
* inner child, because it will always be rescanned with fresh parameter
|
|
|
|
* values.
|
2002-12-05 16:50:39 +01:00
|
|
|
*/
|
2006-02-28 05:10:28 +01:00
|
|
|
outerPlanState(nlstate) = ExecInitNode(outerPlan(node), estate, eflags);
|
2010-07-12 19:01:06 +02:00
|
|
|
if (node->nestParams == NIL)
|
|
|
|
eflags |= EXEC_FLAG_REWIND;
|
|
|
|
else
|
|
|
|
eflags &= ~EXEC_FLAG_REWIND;
|
|
|
|
innerPlanState(nlstate) = ExecInitNode(innerPlan(node), estate, eflags);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2018-02-17 06:17:38 +01:00
|
|
|
* Initialize result slot, type and projection.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
Don't require return slots for nodes without projection.
In a lot of nodes the return slot is not required. That can either be
because the node doesn't do any projection (say an Append node), or
because the node does perform projections but the projection is
optimized away because the projection would yield an identical row.
Slots aren't that small, especially for wide rows, so it's worthwhile
to avoid creating them. It's not possible to just skip creating the
slot - it's currently used to determine the tuple descriptor returned
by ExecGetResultType(). So separate the determination of the result
type from the slot creation. The work previously done internally
ExecInitResultTupleSlotTL() can now also be done separately with
ExecInitResultTypeTL() and ExecInitResultSlot(). That way nodes that
aren't guaranteed to need a result slot, can use
ExecInitResultTypeTL() to determine the result type of the node, and
ExecAssignScanProjectionInfo() (via
ExecConditionalAssignProjectionInfo()) determines that a result slot
is needed, it is created with ExecInitResultSlot().
Besides the advantage of avoiding to create slots that then are
unused, this is necessary preparation for later patches around tuple
table slot abstraction. In particular separating the return descriptor
and slot is a prerequisite to allow JITing of tuple deforming with
knowledge of the underlying tuple format, and to avoid unnecessarily
creating JITed tuple deforming for virtual slots.
This commit removes a redundant argument from
ExecInitResultTupleSlotTL(). While this commit touches a lot of the
relevant lines anyway, it'd normally still not worthwhile to cause
breakage, except that aforementioned later commits will touch *all*
ExecInitResultTupleSlotTL() callers anyway (but fits worse
thematically).
Author: Andres Freund
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-10 02:19:39 +01:00
|
|
|
ExecInitResultTupleSlotTL(&nlstate->js.ps);
|
2018-02-17 06:17:38 +01:00
|
|
|
ExecAssignProjectionInfo(&nlstate->js.ps, NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* initialize child expressions
|
|
|
|
*/
|
|
|
|
nlstate->js.ps.qual =
|
|
|
|
ExecInitQual(node->join.plan.qual, (PlanState *) nlstate);
|
|
|
|
nlstate->js.jointype = node->join.jointype;
|
|
|
|
nlstate->js.joinqual =
|
|
|
|
ExecInitQual(node->join.joinqual, (PlanState *) nlstate);
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2017-04-08 04:20:03 +02:00
|
|
|
/*
|
|
|
|
* detect whether we need only consider the first matching inner tuple
|
|
|
|
*/
|
|
|
|
nlstate->js.single_match = (node->join.inner_unique ||
|
|
|
|
node->join.jointype == JOIN_SEMI);
|
|
|
|
|
|
|
|
/* set up null tuples for outer joins, if needed */
|
2000-09-12 23:07:18 +02:00
|
|
|
switch (node->join.jointype)
|
|
|
|
{
|
|
|
|
case JOIN_INNER:
|
2008-08-14 20:48:00 +02:00
|
|
|
case JOIN_SEMI:
|
2000-09-12 23:07:18 +02:00
|
|
|
break;
|
|
|
|
case JOIN_LEFT:
|
2008-08-14 20:48:00 +02:00
|
|
|
case JOIN_ANTI:
|
2000-09-12 23:07:18 +02:00
|
|
|
nlstate->nl_NullInnerTupleSlot =
|
|
|
|
ExecInitNullTupleSlot(estate,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
ExecGetResultType(innerPlanState(nlstate)));
|
2000-09-12 23:07:18 +02:00
|
|
|
break;
|
|
|
|
default:
|
2003-07-21 19:05:12 +02:00
|
|
|
elog(ERROR, "unrecognized join type: %d",
|
2000-09-12 23:07:18 +02:00
|
|
|
(int) node->join.jointype);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* finally, wipe the current outer tuple clean.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
nlstate->nl_NeedNewOuter = true;
|
|
|
|
nlstate->nl_MatchedOuter = false;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
NL1_printf("ExecInitNestLoop: %s\n",
|
|
|
|
"node initialized");
|
2002-12-05 16:50:39 +01:00
|
|
|
|
|
|
|
return nlstate;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecEndNestLoop
|
|
|
|
*
|
|
|
|
* closes down scans and frees allocated storage
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
void
|
2002-12-05 16:50:39 +01:00
|
|
|
ExecEndNestLoop(NestLoopState *node)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
NL1_printf("ExecEndNestLoop: %s\n",
|
|
|
|
"ending node processing");
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-12-15 17:17:59 +01:00
|
|
|
* Free the exprcontext
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-12-05 16:50:39 +01:00
|
|
|
ExecFreeExprContext(&node->js.ps);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-12-15 17:17:59 +01:00
|
|
|
* clean out the tuple table
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-12-15 17:17:59 +01:00
|
|
|
ExecClearTuple(node->js.ps.ps_ResultTupleSlot);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-12-15 17:17:59 +01:00
|
|
|
* close down subplans
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-12-15 17:17:59 +01:00
|
|
|
ExecEndNode(outerPlanState(node));
|
|
|
|
ExecEndNode(innerPlanState(node));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
NL1_printf("ExecEndNestLoop: %s\n",
|
|
|
|
"node processing ended");
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1998-02-13 04:26:53 +01:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecReScanNestLoop
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
void
|
2010-07-12 19:01:06 +02:00
|
|
|
ExecReScanNestLoop(NestLoopState *node)
|
1998-02-13 04:26:53 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
PlanState *outerPlan = outerPlanState(node);
|
1998-02-13 04:26:53 +01:00
|
|
|
|
|
|
|
/*
|
1998-02-26 05:46:47 +01:00
|
|
|
* If outerPlan->chgParam is not null then plan will be automatically
|
2010-07-12 19:01:06 +02:00
|
|
|
* re-scanned by first ExecProcNode.
|
1998-02-13 04:26:53 +01:00
|
|
|
*/
|
|
|
|
if (outerPlan->chgParam == NULL)
|
2010-07-12 19:01:06 +02:00
|
|
|
ExecReScan(outerPlan);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* innerPlan is re-scanned for each new outer tuple and MUST NOT be
|
|
|
|
* re-scanned from here or you'll get troubles from inner index scans when
|
|
|
|
* outer Vars are used as run-time keys...
|
|
|
|
*/
|
1998-02-13 04:26:53 +01:00
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
node->nl_NeedNewOuter = true;
|
|
|
|
node->nl_MatchedOuter = false;
|
1998-02-13 04:26:53 +01:00
|
|
|
}
|