On Thu, Apr 21, 2016 at 8:57 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> OK, so here's my thoughts. Currently, as mentioned above, I've
> included a PARTIAL prefix for partial aggregates. This is
> syntactically incorrect for the dumping of views etc, but that should
> not matter as partial Aggrefs never come from the parser, they're only
> perhaps generated later in the planner. Same goes for combine
> aggregates too.
Yeah. As I've said a few times, I would like to have SQL syntax that
emits the unfinalized (but serialized, if type internal) values, so
that postgres_fdw can use that to partial aggregation to the remote
side. Maybe we should consider what would be reasonable syntax for
this; but that's a second-order consideration for now.
> The attached still does not get the output into the way Robert would
> have liked, but I still stand by my dislike to pretending the combine
> aggregate is a normal aggregate. It's not all that clear if FILTER
> should be displayed in the combine agg. Combine Aggs don't do FILTER.
I am rather confused by this, for two reasons:
1. The "Output" line is supposed to display the columns that the plan
node is producing. And a FinalizeAggregate had darned well better be
producing the same results as an Aggregate, so it's entirely
reasonable for it to produce the same output that an Aggregate would
have given us.
2. You're using the term "combine agg", but as far as the EXPLAIN
ANALYZE output is concerned, that's not a thing. There is
PartialAggregate, Aggregate, and FinalizeAggregate. I think you mean
FinalizeAggregate when you say "combine aggregate", since we identify
a node as a FinalizeAggregate by observing that combineStates = true.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company