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

On Mon, Jul 27, 2020 at 08:20:45PM -0700, Peter Geoghegan wrote:
> On Mon, Jul 27, 2020 at 5:54 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > hmm. I'm not sure. I think this should follow the same logic as what
> > "Disk Usage" follows, and right now we don't show Disk Usage unless we
> > spill. Since we only use partitions when spilling, I don't think it
> > makes sense to show the estimated partitions when we don't plan on
> > spilling.
>
> I'm confused about what the guiding principles for EXPLAIN ANALYZE
> output (text or otherwise) are.

I don't know of a guideline for text format, but the issues I've raised for
HashAgg and IncrSort are based on previous commits which change to "show field
even if its value is zero" for non-text format:

7d91b604d9b5d6ec8c19c57a9ffd2f27129cdd94
8ebb69f85445177575684a0ba5cfedda8d840a91
3ec20c7091e97a554e7447ac2b7f4ed795631395

> > I think if we change this then we should change Disk Usage too.
> > However, I don't think we should as Sort will only show "Disk" if the
> > sort spills. I think Hash Agg should follow that.
>
> I don't follow your remarks here.
>
> 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.)

Note that I did mail recently, on this 2nd thread:

https://www.postgresql.org/message-id/20200723141454.GF4286@telsasoft.com

--
Justin