Re: EXPLAIN VERBOSE with parallel Aggregate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXPLAIN VERBOSE with parallel Aggregate
Date: 2016-04-17 14:22:24
Message-ID: 27515.1460902944@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On 16 April 2016 at 04:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> +1 for the latter, if we can do it conveniently. I think exposing
>> the names of the aggregate implementation functions would be very
>> user-unfriendly, as nobody but us hackers knows what those are.

> It does not really seem all that convenient to do this. It also seems
> a bit strange to me to have a parent node report a column which does
> not exist in any nodes descending from it. Remember that the combine
> Aggref does not have the same ->args as its corresponding partial
> Aggref. It's not all that clear to me if there is any nice way to do
> have this work the way you'd like. If we were to just call
> get_rule_expr() on the first arg of the combine aggregate node, it
> would re-print the PARTIAL keyword again.

This suggests to me that the parsetree representation for partial
aggregates was badly chosen. If EXPLAIN can't recognize them, then
neither can anything else, and we may soon find needs for telling
the difference that are not just cosmetic. Maybe we need more
fields in Aggref.

> Note that I've done nothing for the weird schema prefixing problem I
> mentioned. I think I'd need input on the best way to solve this. If
> it's actually a problem.

It sure looks like a problem to me. Maybe it's only cosmetic, but
it's going to cause confusion and bug reports. EXPLAIN output for
parallel queries is going to be confusing enough anyway; we need
to avoid having artifacts like this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-04-17 15:46:42 Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Craig Ringer 2016-04-17 14:01:36 Re: Timeline following for logical slots