Re: EXPLAIN VERBOSE with parallel Aggregate

On Tue, Apr 19, 2016 at 9:22 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Sun, Apr 17, 2016 at 10:22:24AM -0400, Tom Lane wrote:
>> 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.
>
> [This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 9.6 open item. Robert,
> since you committed the patch believed to have created it, you own this open
> item. If that responsibility lies elsewhere, please let us know whose
> responsibility it is to fix this. Since new open items may be discovered at
> any time and I want to plan to have them all fixed well in advance of the ship
> date, I will appreciate your efforts toward speedy resolution. Please
> present, within 72 hours, a plan to fix the defect within seven days of this
> message. Thanks.

I'll do my best to work on this soon. I'm not happy with the output
produced by David's patch, but I don't expect I'll be able to do
better without putting some time into it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company