Horton

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: David Rowley <dgrowleyml@gmail.com>, James Coleman <jtc331@gmail.com>, Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@lists.postgresql.org
Date: 2020-07-31T01:40:27Z
Lists: pgsql-hackers 
On Thu, Jul 30, 2020 at 06:33:32PM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > Because filtering out zero values is exactly what's intended to be avoided for
> > nontext output.
> >
> > I think checking whether the method was used should result in the same output,
> > without the literal check for zero value (which itself sets a bad example).
> 
> It seems fine to me as-is. What about SORT_TYPE_TOP_N_HEAPSORT? Or any
> other sort methods we add in the future?

Feel free to close it out.  I'm satisfied that we've had a discussion about it.

-- 
Justin

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.