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