Re: EXPLAIN VERBOSE with parallel Aggregate

On Mon, Apr 25, 2016 at 1:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Yeah, I'd be happy to have more people chime in.  I think your example
> is interesting, but it doesn't persuade me, because the rule has
> always been that EXPLAIN shows the output *columns*, not the output
> *rows*.  The disappearance of some rows doesn't change the list of
> output columns.  For scans and joins this rule is easy to apply; for
> aggregates, where many rows become one, less so.  Some of the existing
> choices there are certainly arguable, like the fact that FILTER is
> shown anywhere at all, which seems like an artifact to me.  But I
> think that now is not the time to rethink those decisions.

My proposed fix for this issue is attached.  Review is welcome;
otherwise, I'll just commit this.  The output looks like what I
suggested upthread:

rhaas=# explain verbose select count(*), corr(aid, bid) from pgbench_accounts ;
                                                  QUERY PLAN
--------------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=742804.22..742804.23 rows=1 width=16)
   Output: count(*), corr((aid)::double precision, (bid)::double precision)
   ->  Gather  (cost=742804.00..742804.21 rows=2 width=40)
         Output: (PARTIAL count(*)), (PARTIAL corr((aid)::double
precision, (bid)::double precision))
         Workers Planned: 2
         ->  Partial Aggregate  (cost=741804.00..741804.01 rows=1 width=40)
               Output: PARTIAL count(*), PARTIAL corr((aid)::double
precision, (bid)::double precision)
               ->  Parallel Seq Scan on public.pgbench_accounts
(cost=0.00..616804.00 rows=12500000 width=8)
                     Output: aid, bid, abalance, filler
(9 rows)

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