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
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, 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
|
|
|
*/
|
Introduce notion of different types of slots (without implementing them).
Upcoming work intends to allow pluggable ways to introduce new ways of
storing table data. Accessing those table access methods from the
executor requires TupleTableSlots to be carry tuples in the native
format of such storage methods; otherwise there'll be a significant
conversion overhead.
Different access methods will require different data to store tuples
efficiently (just like virtual, minimal, heap already require fields
in TupleTableSlot). To allow that without requiring additional pointer
indirections, we want to have different structs (embedding
TupleTableSlot) for different types of slots. Thus different types of
slots are needed, which requires adapting creators of slots.
The slot that most efficiently can represent a type of tuple in an
executor node will often depend on the type of slot a child node
uses. Therefore we need to track the type of slot is returned by
nodes, so parent slots can create slots based on that.
Relatedly, JIT compilation of tuple deforming needs to know which type
of slot a certain expression refers to, so it can create an
appropriate deforming function for the type of tuple in the slot.
But not all nodes will only return one type of slot, e.g. an append
node will potentially return different types of slots for each of its
subplans.
Therefore add function that allows to query the type of a node's
result slot, and whether it'll always be the same type (whether it's
fixed). This can be queried using ExecGetResultSlotOps().
The scan, result, inner, outer type of slots are automatically
inferred from ExecInitScanTupleSlot(), ExecInitResultSlot(),
left/right subtrees respectively. If that's not correct for a node,
that can be overwritten using new fields in PlanState.
This commit does not introduce the actually abstracted implementation
of different kind of TupleTableSlots, that will be left for a followup
commit. The different types of slots introduced will, for now, still
use the same backing implementation.
While this already partially invalidates the big comment in
tuptable.h, it seems to make more sense to update it later, when the
different TupleTableSlot implementations actually exist.
Author: Ashutosh Bapat and Andres Freund, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-16 07:00:30 +01:00
|
|
|
ExecInitResultTupleSlotTL(&nlstate->js.ps, &TTSOpsVirtual);
|
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,
|
Introduce notion of different types of slots (without implementing them).
Upcoming work intends to allow pluggable ways to introduce new ways of
storing table data. Accessing those table access methods from the
executor requires TupleTableSlots to be carry tuples in the native
format of such storage methods; otherwise there'll be a significant
conversion overhead.
Different access methods will require different data to store tuples
efficiently (just like virtual, minimal, heap already require fields
in TupleTableSlot). To allow that without requiring additional pointer
indirections, we want to have different structs (embedding
TupleTableSlot) for different types of slots. Thus different types of
slots are needed, which requires adapting creators of slots.
The slot that most efficiently can represent a type of tuple in an
executor node will often depend on the type of slot a child node
uses. Therefore we need to track the type of slot is returned by
nodes, so parent slots can create slots based on that.
Relatedly, JIT compilation of tuple deforming needs to know which type
of slot a certain expression refers to, so it can create an
appropriate deforming function for the type of tuple in the slot.
But not all nodes will only return one type of slot, e.g. an append
node will potentially return different types of slots for each of its
subplans.
Therefore add function that allows to query the type of a node's
result slot, and whether it'll always be the same type (whether it's
fixed). This can be queried using ExecGetResultSlotOps().
The scan, result, inner, outer type of slots are automatically
inferred from ExecInitScanTupleSlot(), ExecInitResultSlot(),
left/right subtrees respectively. If that's not correct for a node,
that can be overwritten using new fields in PlanState.
This commit does not introduce the actually abstracted implementation
of different kind of TupleTableSlots, that will be left for a followup
commit. The different types of slots introduced will, for now, still
use the same backing implementation.
While this already partially invalidates the big comment in
tuptable.h, it seems to make more sense to update it later, when the
different TupleTableSlot implementations actually exist.
Author: Ashutosh Bapat and Andres Freund, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-16 07:00:30 +01:00
|
|
|
ExecGetResultType(innerPlanState(nlstate)),
|
|
|
|
&TTSOpsVirtual);
|
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
|
|
|
}
|