Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. - Mailing list pgsql-hackers

From David Rowley
Subject Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Date
Msg-id CAApHDvr9+jAN2M-BJk8dYoKyvcJMHiF67BANwKmjBHC9pdnU3A@mail.gmail.com
Whole thread Raw
In response to Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.  (Peter Geoghegan <pg@bowt.ie>)
List 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



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Next
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions