aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2008-08-02 21:32:01 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2008-08-02 21:32:01 +0000
commit951130475221562b44b0da575fac8470adb5b555 (patch)
tree5dc2ac24a5381a2ff1c2f25e1d14430b66558c02 /src/backend/executor
parent49f001d81ed635747c4439f38ae1fc6090887452 (diff)
downloadpostgresql-951130475221562b44b0da575fac8470adb5b555.tar.gz
postgresql-951130475221562b44b0da575fac8470adb5b555.zip
Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT items
as per my recent proposal: 1. Fold SortClause and GroupClause into a single node type SortGroupClause. We were already relying on them to be struct-equivalent, so using two node tags wasn't accomplishing much except to get in the way of comparing items with equal(). 2. Add an "eqop" field to SortGroupClause to carry the associated equality operator. This is cheap for the parser to get at the same time it's looking up the sort operator, and storing it eliminates the need for repeated not-so-cheap lookups during planning. In future this will also let us represent GROUP/DISTINCT operations on datatypes that have hash opclasses but no btree opclasses (ie, they have equality but no natural sort order). The previous representation simply didn't work for that, since its only indicator of comparison semantics was a sort operator. 3. Add a hasDistinctOn boolean to struct Query to explicitly record whether the distinctClause came from DISTINCT or DISTINCT ON. This allows removing some complicated and not 100% bulletproof code that attempted to figure that out from the distinctClause alone. This patch doesn't in itself create any new capability, but it's necessary infrastructure for future attempts to use hash-based grouping for DISTINCT and UNION/INTERSECT/EXCEPT.
Diffstat (limited to 'src/backend/executor')
-rw-r--r--src/backend/executor/nodeAgg.c13
1 files changed, 8 insertions, 5 deletions
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
index 00bd21ba6f2..9bcff0f8dfe 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.158 2008/05/12 00:00:49 alvherre Exp $
+ * $PostgreSQL: pgsql/src/backend/executor/nodeAgg.c,v 1.159 2008/08/02 21:31:59 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -1496,7 +1496,8 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
if (aggref->aggdistinct)
{
- Oid eq_function;
+ Oid lt_opr;
+ Oid eq_opr;
/* We don't implement DISTINCT aggs in the HASHED case */
Assert(node->aggstrategy != AGG_HASHED);
@@ -1524,9 +1525,11 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
* 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]);
+ get_sort_group_operators(inputTypes[0],
+ true, true, false,
+ &lt_opr, &eq_opr, NULL);
+ fmgr_info(get_opcode(eq_opr), &(peraggstate->equalfn));
+ peraggstate->sortOperator = lt_opr;
peraggstate->sortstate = NULL;
}