On 23 April 2016 at 13:58, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Apr 22, 2016 at 5:36 PM, David Rowley
> <david.rowley@2ndquadrant.com> wrote:
>> I really don't think that we should print FILTER details in a combine
>> aggregate node. We'd be claiming to be doing something that we're
>> actually not doing. Please see advance_aggregates() in nodeAgg.c, and
>> compare that to combine_aggregates(), which is used when combineStates
>> == true. Notice that only advance_aggregates() bothers with the
>> aggfilter clause.
>
> I think you're wrong. The Output line says what that node outputs,
> not how it's computed. And a FinalizeAggregate on top of a
> PartialAggregate produces the same output as an Aggregate.
The most basic thing I can think of to rationalise my thinking for this is:
# create table v (v varchar);
# create view v_v as select lower(v) v from v;
# explain verbose select upper(v) from v_v; QUERY PLAN
-------------------------------------------------------------Seq Scan on public.v (cost=0.00..30.40 rows=1360
width=32) Output: upper(lower((v.v)::text))
(2 rows)
It seems that you're proposing that the aggregate equivalence of this should be;
QUERY PLAN
-------------------------------------------------------------Seq Scan on public.v (cost=0.00..30.40 rows=1360
width=32) Output: upper((v)::text)
(2 rows)
which to me seems wrong, as it's hiding the fact that lower() was called.
My arguments don't seem to be holding much weight, so I'll back down,
although it would still be interesting to hear what others have to say
about this.
In any case, thanks for stepping up to fix this. I'm sure what you're
proposing will be much better than what's there at the moment.
-- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services