Horton

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-28T04:08:34Z
Lists: pgsql-hackers 
On Tue, 28 Jul 2020 at 15:21, Peter Geoghegan <pg@bowt.ie> wrote:
> Separately, I wonder what your opinion is about what should happen for
> the partial sort related EXPLAIN ANALYZE format open item, described
> here:
>
> https://www.postgresql.org/message-id/flat/20200619040358.GZ17995%40telsasoft.com#b20bd205851a0390220964f7c31b23d1
>
> ISTM that EXPLAIN ANALYZE for incremental sort manages to show the
> same information as the sort case, aggregated across each tuplesort in
> a fairly sensible way.
>
> (No activity over on the incremental sort thread, so I thought I'd ask
> again here, while I was reminded of that issue.)

TBH, I've not really looked at that.

Tom did mention his view on this in [1]. I think that's a pretty good
policy. However, I've not looked at the incremental sort EXPLAIN
output enough to know how it'll best apply there.

David

[1] https://www.postgresql.org/message-id/2276865.1593102811%40sss.pgh.pa.us

Commits

  1. Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join

  2. Further adjustments to Hashagg EXPLAIN ANALYZE output

  3. Fix handling of "Subplans Removed" field in EXPLAIN output.

  4. Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields.

  5. Fix some infelicities in EXPLAIN output for parallel query plans.