aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeAgg.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2007-01-10 18:06:05 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2007-01-10 18:06:05 +0000
commita191a169d6d0b9558da4519e66510c4540204a51 (patch)
treecd32b62bc013145015f4932fef1f7687737205b3 /src/backend/executor/nodeAgg.c
parent5f6d735356c9090d87e184c9322bfe37a165a014 (diff)
downloadpostgresql-a191a169d6d0b9558da4519e66510c4540204a51.tar.gz
postgresql-a191a169d6d0b9558da4519e66510c4540204a51.zip
Change the planner-to-executor API so that the planner tells the executor
which comparison operators to use for plan nodes involving tuple comparison (Agg, Group, Unique, SetOp). Formerly the executor looked up the default equality operator for the datatype, which was really pretty shaky, since it's possible that the data being fed to the node is sorted according to some nondefault operator class that could have an incompatible idea of equality. The planner knows what it has sorted by and therefore can provide the right equality operator to use. Also, this change moves a couple of catalog lookups out of the executor and into the planner, which should help startup time for pre-planned queries by some small amount. Modify the planner to remove some other cavalier assumptions about always being able to use the default operators. Also add "nulls first/last" info to the Plan node for a mergejoin --- neither the executor nor the planner can cope yet, but at least the API is in place.
Diffstat (limited to 'src/backend/executor/nodeAgg.c')
-rw-r--r--src/backend/executor/nodeAgg.c19
1 files changed, 12 insertions, 7 deletions
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
index 74a00ac8920..00fb3b86e71 100644
--- a/src/backend/executor/nodeAgg.c
+++ b/src/backend/executor/nodeAgg.c
@@ -61,7 +61,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/executor/nodeAgg.c,v 1.148 2007/01/09 02:14:11 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/executor/nodeAgg.c,v 1.149 2007/01/10 18:06:02 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -1270,16 +1270,14 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
if (node->numCols > 0)
{
if (node->aggstrategy == AGG_HASHED)
- execTuplesHashPrepare(ExecGetScanType(&aggstate->ss),
- node->numCols,
- node->grpColIdx,
+ execTuplesHashPrepare(node->numCols,
+ node->grpOperators,
&aggstate->eqfunctions,
&aggstate->hashfunctions);
else
aggstate->eqfunctions =
- execTuplesMatchPrepare(ExecGetScanType(&aggstate->ss),
- node->numCols,
- node->grpColIdx);
+ execTuplesMatchPrepare(node->numCols,
+ node->grpOperators);
}
/*
@@ -1519,6 +1517,13 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
&peraggstate->inputtypeLen,
&peraggstate->inputtypeByVal);
+ /*
+ * Look up the sorting and comparison operators to use. XXX it's
+ * pretty bletcherous to be making this sort of semantic decision
+ * in the executor. Probably the parser should decide this and
+ * record it in the Aggref node ... or at latest, do it in the
+ * planner.
+ */
eq_function = equality_oper_funcid(inputTypes[0]);
fmgr_info(eq_function, &(peraggstate->equalfn));
peraggstate->sortOperator = ordering_oper_opid(inputTypes[0]);