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: James Coleman <jtc331@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, David Rowley <dgrowleyml@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-31T01:43:55Z
Lists: pgsql-hackers 
On Thu, Jul 30, 2020 at 6:39 PM James Coleman <jtc331@gmail.com> wrote:
> I very much do not like this approach, and I think it's actually fundamentally wrong, at least for the memory check. Quicksort is not the only option that uses memory. For now, there's only one option that spills to disk (external merge sort), but there's no reason it has to remain that way.

I wouldn't be surprised if it was possible to get
SORT_TYPE_EXTERNAL_SORT even today (though I'm not sure if that's
truly possible). That will happen for a regular sort node if we
require randomAccess to the sort, and it happens to spill -- we can
randomly access the final tape, but cannot do a final on-the-fly
merge. Say for a merge join.

-- 
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.