mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
Support ORDER BY within aggregate function calls, at long last providing a
non-kluge method for controlling the order in which values are fed to an aggregate function. At the same time eliminate the old implementation restriction that DISTINCT was only supported for single-argument aggregates. Possibly release-notable behavioral change: formerly, agg(DISTINCT x) dropped null values of x unconditionally. Now, it does so only if the agg transition function is strict; otherwise nulls are treated as DISTINCT normally would, ie, you get one copy. Andrew Gierth, reviewed by Hitoshi Harada
This commit is contained in:
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.261 2009/10/28 14:55:38 tgl Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.262 2009/12/15 17:57:46 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -1096,11 +1096,12 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
|
||||
bool can_sort;
|
||||
|
||||
/*
|
||||
* Executor doesn't support hashed aggregation with DISTINCT
|
||||
* aggregates. (Doing so would imply storing *all* the input
|
||||
* values in the hash table, which seems like a certain loser.)
|
||||
* Executor doesn't support hashed aggregation with DISTINCT or
|
||||
* ORDER BY aggregates. (Doing so would imply storing *all* the
|
||||
* input values in the hash table, and/or running many sorts in
|
||||
* parallel, either of which seems like a certain loser.)
|
||||
*/
|
||||
can_hash = (agg_counts.numDistinctAggs == 0 &&
|
||||
can_hash = (agg_counts.numOrderedAggs == 0 &&
|
||||
grouping_is_hashable(parse->groupClause));
|
||||
can_sort = grouping_is_sortable(parse->groupClause);
|
||||
if (can_hash && can_sort)
|
||||
|
Reference in New Issue
Block a user