Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: David Rowley <dgrowleyml@gmail.com>, James Coleman <jtc331@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-31T01:33:32Z
Lists: pgsql-hackers 
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?

The way that we flatten maxDiskSpaceUsed and maxMemorySpaceUsed into
"space used" on output might be kind of questionable, but it's
something that we have to live with for the foreseeable future. I
don't think that this is a bad example -- we don't output
maxDiskSpaceUsed or maxMemorySpaceUsed at the conceptual level.

-- 
Peter Geoghegan

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.