1996-07-09 02:22:35 -04:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-13 18:22:53 -05:00
|
|
|
* nodeGroup.c
|
1997-09-07 01:04:48 -04:00
|
|
|
* Routines to handle group nodes (used for queries with GROUP BY clause).
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
2018-01-02 23:30:12 -05:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2000-01-26 00:58:53 -05:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* DESCRIPTION
|
1997-09-07 01:04:48 -04:00
|
|
|
* The Group node is designed for handling queries with a GROUP BY clause.
|
2000-01-27 13:11:50 -05:00
|
|
|
* Its outer plan must deliver tuples that are sorted in the order
|
|
|
|
|
* specified by the grouping columns (ie. tuples from the same group are
|
|
|
|
|
* consecutive). That way, we just have to compare adjacent tuples to
|
|
|
|
|
* locate group boundaries.
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
|
|
|
|
* IDENTIFICATION
|
2010-09-20 16:08:53 -04:00
|
|
|
* src/backend/executor/nodeGroup.c
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
1997-01-10 15:19:49 -05:00
|
|
|
|
1996-10-31 05:12:26 -05:00
|
|
|
#include "postgres.h"
|
|
|
|
|
|
1996-07-09 02:22:35 -04:00
|
|
|
#include "executor/executor.h"
|
|
|
|
|
#include "executor/nodeGroup.h"
|
2017-07-25 20:37:17 -04:00
|
|
|
#include "miscadmin.h"
|
2018-02-16 00:55:31 -05:00
|
|
|
#include "utils/memutils.h"
|
1996-07-09 02:22:35 -04:00
|
|
|
|
|
|
|
|
|
2002-11-05 19:00:45 -05:00
|
|
|
/*
|
1997-09-07 01:04:48 -04:00
|
|
|
* ExecGroup -
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
2002-11-05 19:00:45 -05:00
|
|
|
* Return one tuple for each group of matching input tuples.
|
1996-07-09 02:22:35 -04:00
|
|
|
*/
|
2017-07-17 03:33:49 -04:00
|
|
|
static TupleTableSlot *
|
|
|
|
|
ExecGroup(PlanState *pstate)
|
1996-07-09 02:22:35 -04:00
|
|
|
{
|
2017-07-17 03:33:49 -04:00
|
|
|
GroupState *node = castNode(GroupState, pstate);
|
1997-09-07 22:41:22 -04:00
|
|
|
ExprContext *econtext;
|
2005-03-16 16:38:10 -05:00
|
|
|
TupleTableSlot *firsttupleslot;
|
1998-02-18 07:40:44 -05:00
|
|
|
TupleTableSlot *outerslot;
|
1996-07-09 02:22:35 -04:00
|
|
|
|
2017-07-25 20:37:17 -04:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
|
2001-03-22 01:16:21 -05:00
|
|
|
/*
|
|
|
|
|
* get state info from node
|
1997-09-07 01:04:48 -04:00
|
|
|
*/
|
2002-12-05 10:50:39 -05:00
|
|
|
if (node->grp_done)
|
1997-09-07 01:04:48 -04:00
|
|
|
return NULL;
|
2002-12-05 10:50:39 -05:00
|
|
|
econtext = node->ss.ps.ps_ExprContext;
|
2000-01-27 13:11:50 -05:00
|
|
|
|
2005-03-16 16:38:10 -05:00
|
|
|
/*
|
|
|
|
|
* The ScanTupleSlot holds the (copied) first tuple of each group.
|
|
|
|
|
*/
|
|
|
|
|
firsttupleslot = node->ss.ss_ScanTupleSlot;
|
|
|
|
|
|
2000-07-11 22:37:39 -04:00
|
|
|
/*
|
2018-02-16 00:55:31 -05:00
|
|
|
* We need not call ResetExprContext here because ExecQualAndReset() will
|
2001-03-21 23:01:46 -05:00
|
|
|
* reset the per-tuple memory context once per input tuple.
|
2000-07-11 22:37:39 -04:00
|
|
|
*/
|
|
|
|
|
|
2005-03-10 18:21:26 -05:00
|
|
|
/*
|
2005-10-14 22:49:52 -04:00
|
|
|
* If first time through, acquire first input tuple and determine whether
|
|
|
|
|
* to return it or not.
|
2005-03-10 18:21:26 -05:00
|
|
|
*/
|
2005-03-16 16:38:10 -05:00
|
|
|
if (TupIsNull(firsttupleslot))
|
1997-09-07 01:04:48 -04:00
|
|
|
{
|
2002-12-05 10:50:39 -05:00
|
|
|
outerslot = ExecProcNode(outerPlanState(node));
|
1998-11-27 14:52:36 -05:00
|
|
|
if (TupIsNull(outerslot))
|
1997-09-07 01:04:48 -04:00
|
|
|
{
|
2005-03-10 18:21:26 -05:00
|
|
|
/* empty input, so return nothing */
|
2017-08-16 00:22:32 -04:00
|
|
|
node->grp_done = true;
|
1997-09-07 01:04:48 -04:00
|
|
|
return NULL;
|
|
|
|
|
}
|
2007-02-22 18:44:25 -05:00
|
|
|
/* Copy tuple into firsttupleslot */
|
2005-03-16 16:38:10 -05:00
|
|
|
ExecCopySlot(firsttupleslot, outerslot);
|
2007-02-22 18:44:25 -05:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set it up as input for qual test and projection. The expressions
|
|
|
|
|
* will access the input tuple as varno OUTER.
|
|
|
|
|
*/
|
|
|
|
|
econtext->ecxt_outertuple = firsttupleslot;
|
2005-10-14 22:49:52 -04:00
|
|
|
|
2005-03-10 18:21:26 -05:00
|
|
|
/*
|
2005-10-14 22:49:52 -04:00
|
|
|
* Check the qual (HAVING clause); if the group does not match, ignore
|
|
|
|
|
* it and fall into scan loop.
|
2005-03-10 18:21:26 -05:00
|
|
|
*/
|
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 18:45:36 -04:00
|
|
|
if (ExecQual(node->ss.ps.qual, econtext))
|
2005-03-10 18:21:26 -05:00
|
|
|
{
|
|
|
|
|
/*
|
2005-10-14 22:49:52 -04:00
|
|
|
* Form and return a projection tuple using the first input tuple.
|
2005-03-10 18:21:26 -05:00
|
|
|
*/
|
2017-01-19 17:12:38 -05:00
|
|
|
return ExecProject(node->ss.ps.ps_ProjInfo);
|
2005-03-10 18:21:26 -05:00
|
|
|
}
|
2011-09-22 11:29:18 -04:00
|
|
|
else
|
|
|
|
|
InstrCountFiltered1(node, 1);
|
1996-07-09 02:22:35 -04:00
|
|
|
}
|
|
|
|
|
|
1997-09-07 01:04:48 -04:00
|
|
|
/*
|
2005-03-10 18:21:26 -05:00
|
|
|
* This loop iterates once per input tuple group. At the head of the
|
2005-10-14 22:49:52 -04:00
|
|
|
* loop, we have finished processing the first tuple of the group and now
|
|
|
|
|
* need to scan over all the other group members.
|
1996-07-09 02:22:35 -04:00
|
|
|
*/
|
1997-09-07 01:04:48 -04:00
|
|
|
for (;;)
|
|
|
|
|
{
|
2005-03-10 18:21:26 -05:00
|
|
|
/*
|
|
|
|
|
* Scan over all remaining tuples that belong to this group
|
|
|
|
|
*/
|
|
|
|
|
for (;;)
|
1997-09-07 01:04:48 -04:00
|
|
|
{
|
2005-03-10 18:21:26 -05:00
|
|
|
outerslot = ExecProcNode(outerPlanState(node));
|
|
|
|
|
if (TupIsNull(outerslot))
|
|
|
|
|
{
|
|
|
|
|
/* no more groups, so we're done */
|
2017-08-16 00:22:32 -04:00
|
|
|
node->grp_done = true;
|
2005-03-10 18:21:26 -05:00
|
|
|
return NULL;
|
|
|
|
|
}
|
1997-09-07 01:04:48 -04:00
|
|
|
|
2005-03-10 18:21:26 -05:00
|
|
|
/*
|
|
|
|
|
* Compare with first tuple and see if this tuple is of the same
|
|
|
|
|
* group. If so, ignore it and keep scanning.
|
|
|
|
|
*/
|
2018-02-16 00:55:31 -05:00
|
|
|
econtext->ecxt_innertuple = firsttupleslot;
|
|
|
|
|
econtext->ecxt_outertuple = outerslot;
|
|
|
|
|
if (!ExecQualAndReset(node->eqfunction, econtext))
|
2005-03-10 18:21:26 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2005-10-14 22:49:52 -04:00
|
|
|
|
2000-01-27 13:11:50 -05:00
|
|
|
/*
|
2005-10-14 22:49:52 -04:00
|
|
|
* We have the first tuple of the next input group. See if we want to
|
|
|
|
|
* return it.
|
1997-09-07 01:04:48 -04:00
|
|
|
*/
|
2005-03-16 16:38:10 -05:00
|
|
|
/* Copy tuple, set up as input for qual test and projection */
|
|
|
|
|
ExecCopySlot(firsttupleslot, outerslot);
|
2007-02-22 18:44:25 -05:00
|
|
|
econtext->ecxt_outertuple = firsttupleslot;
|
2005-10-14 22:49:52 -04:00
|
|
|
|
2005-03-10 18:21:26 -05:00
|
|
|
/*
|
2005-10-14 22:49:52 -04:00
|
|
|
* Check the qual (HAVING clause); if the group does not match, ignore
|
|
|
|
|
* it and loop back to scan the rest of the group.
|
2005-03-10 18:21:26 -05:00
|
|
|
*/
|
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 18:45:36 -04:00
|
|
|
if (ExecQual(node->ss.ps.qual, econtext))
|
2005-03-10 18:21:26 -05:00
|
|
|
{
|
|
|
|
|
/*
|
2005-10-14 22:49:52 -04:00
|
|
|
* Form and return a projection tuple using the first input tuple.
|
2005-03-10 18:21:26 -05:00
|
|
|
*/
|
2017-01-19 17:12:38 -05:00
|
|
|
return ExecProject(node->ss.ps.ps_ProjInfo);
|
2005-03-10 18:21:26 -05:00
|
|
|
}
|
2011-09-22 11:29:18 -04:00
|
|
|
else
|
|
|
|
|
InstrCountFiltered1(node, 1);
|
1998-02-18 07:40:44 -05:00
|
|
|
}
|
1996-07-09 02:22:35 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* -----------------
|
1997-09-07 01:04:48 -04:00
|
|
|
* ExecInitGroup
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
1997-09-07 01:04:48 -04:00
|
|
|
* Creates the run-time information for the group node produced by the
|
|
|
|
|
* planner and initializes its outer subtree
|
1996-07-09 02:22:35 -04:00
|
|
|
* -----------------
|
|
|
|
|
*/
|
2002-12-05 10:50:39 -05:00
|
|
|
GroupState *
|
2006-02-27 23:10:28 -05:00
|
|
|
ExecInitGroup(Group *node, EState *estate, int eflags)
|
1996-07-09 02:22:35 -04:00
|
|
|
{
|
1997-09-07 22:41:22 -04:00
|
|
|
GroupState *grpstate;
|
1997-09-07 01:04:48 -04:00
|
|
|
|
2006-02-27 23:10:28 -05:00
|
|
|
/* check for unsupported flags */
|
|
|
|
|
Assert(!(eflags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)));
|
|
|
|
|
|
1997-09-07 01:04:48 -04:00
|
|
|
/*
|
|
|
|
|
* create state structure
|
|
|
|
|
*/
|
|
|
|
|
grpstate = makeNode(GroupState);
|
2002-12-05 10:50:39 -05:00
|
|
|
grpstate->ss.ps.plan = (Plan *) node;
|
|
|
|
|
grpstate->ss.ps.state = estate;
|
2017-07-17 03:33:49 -04:00
|
|
|
grpstate->ss.ps.ExecProcNode = ExecGroup;
|
2017-08-16 00:22:32 -04:00
|
|
|
grpstate->grp_done = false;
|
1997-09-07 01:04:48 -04:00
|
|
|
|
|
|
|
|
/*
|
2000-07-11 22:37:39 -04:00
|
|
|
* create expression context
|
1997-09-07 01:04:48 -04:00
|
|
|
*/
|
2002-12-05 10:50:39 -05:00
|
|
|
ExecAssignExprContext(estate, &grpstate->ss.ps);
|
1997-09-07 01:04:48 -04:00
|
|
|
|
2002-12-05 10:50:39 -05:00
|
|
|
/*
|
|
|
|
|
* initialize child nodes
|
|
|
|
|
*/
|
2006-02-27 23:10:28 -05:00
|
|
|
outerPlanState(grpstate) = ExecInitNode(outerPlan(node), estate, eflags);
|
1997-09-07 01:04:48 -04:00
|
|
|
|
2001-03-22 01:16:21 -05:00
|
|
|
/*
|
2018-02-17 00:17:38 -05:00
|
|
|
* Initialize scan slot and type.
|
1997-09-07 01:04:48 -04:00
|
|
|
*/
|
2018-02-17 00:17:38 -05:00
|
|
|
ExecCreateScanSlotFromOuterPlan(estate, &grpstate->ss);
|
1997-09-07 01:04:48 -04:00
|
|
|
|
|
|
|
|
/*
|
2018-02-17 00:17:38 -05:00
|
|
|
* Initialize result slot, type and projection.
|
1997-09-07 01:04:48 -04: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-09 20:19:39 -05:00
|
|
|
ExecInitResultTupleSlotTL(&grpstate->ss.ps);
|
2007-02-01 19:07:03 -05:00
|
|
|
ExecAssignProjectionInfo(&grpstate->ss.ps, NULL);
|
1997-09-07 01:04:48 -04:00
|
|
|
|
2018-02-17 00:17:38 -05:00
|
|
|
/*
|
|
|
|
|
* initialize child expressions
|
|
|
|
|
*/
|
|
|
|
|
grpstate->ss.ps.qual =
|
|
|
|
|
ExecInitQual(node->plan.qual, (PlanState *) grpstate);
|
|
|
|
|
|
2000-01-27 13:11:50 -05:00
|
|
|
/*
|
|
|
|
|
* Precompute fmgr lookup data for inner loop
|
|
|
|
|
*/
|
2018-02-16 00:55:31 -05:00
|
|
|
grpstate->eqfunction =
|
|
|
|
|
execTuplesMatchPrepare(ExecGetResultType(outerPlanState(grpstate)),
|
|
|
|
|
node->numCols,
|
2018-02-18 23:32:56 -05:00
|
|
|
node->grpColIdx,
|
2018-02-16 00:55:31 -05:00
|
|
|
node->grpOperators,
|
|
|
|
|
&grpstate->ss.ps);
|
2000-01-27 13:11:50 -05:00
|
|
|
|
2002-12-05 10:50:39 -05:00
|
|
|
return grpstate;
|
1996-07-09 02:22:35 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ------------------------
|
1997-09-07 01:04:48 -04:00
|
|
|
* ExecEndGroup(node)
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
|
|
|
|
* -----------------------
|
|
|
|
|
*/
|
|
|
|
|
void
|
2002-12-05 10:50:39 -05:00
|
|
|
ExecEndGroup(GroupState *node)
|
1996-07-09 02:22:35 -04:00
|
|
|
{
|
2002-12-05 10:50:39 -05:00
|
|
|
PlanState *outerPlan;
|
1996-07-09 02:22:35 -04:00
|
|
|
|
2002-12-05 10:50:39 -05:00
|
|
|
ExecFreeExprContext(&node->ss.ps);
|
1996-07-09 02:22:35 -04:00
|
|
|
|
1997-09-07 01:04:48 -04:00
|
|
|
/* clean up tuple table */
|
2002-12-05 10:50:39 -05:00
|
|
|
ExecClearTuple(node->ss.ss_ScanTupleSlot);
|
2002-12-15 11:17:59 -05:00
|
|
|
|
|
|
|
|
outerPlan = outerPlanState(node);
|
|
|
|
|
ExecEndNode(outerPlan);
|
1996-07-09 02:22:35 -04:00
|
|
|
}
|
|
|
|
|
|
2000-01-27 13:11:50 -05:00
|
|
|
void
|
2010-07-12 13:01:06 -04:00
|
|
|
ExecReScanGroup(GroupState *node)
|
2000-01-27 13:11:50 -05:00
|
|
|
{
|
2015-05-23 21:35:49 -04:00
|
|
|
PlanState *outerPlan = outerPlanState(node);
|
2015-05-04 16:13:07 -04:00
|
|
|
|
2017-08-16 00:22:32 -04:00
|
|
|
node->grp_done = false;
|
2005-03-16 16:38:10 -05:00
|
|
|
/* must clear first tuple */
|
|
|
|
|
ExecClearTuple(node->ss.ss_ScanTupleSlot);
|
2000-01-27 13:11:50 -05:00
|
|
|
|
2010-07-12 13:01:06 -04:00
|
|
|
/*
|
|
|
|
|
* if chgParam of subnode is not null then plan will be re-scanned by
|
|
|
|
|
* first ExecProcNode.
|
|
|
|
|
*/
|
2015-05-04 16:13:07 -04:00
|
|
|
if (outerPlan->chgParam == NULL)
|
|
|
|
|
ExecReScan(outerPlan);
|
2000-01-27 13:11:50 -05:00
|
|
|
}
|