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

From Peter Geoghegan
Subject Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)
Date
Msg-id CAH2-WzmF329695BUkeVWMSgz642m2R=cHSM6YhkRLve_XupJSw@mail.gmail.com
Whole thread Raw
In response to Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)  (James Coleman <jtc331@gmail.com>)
List 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.
Quicksortis 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



pgsql-hackers by date:

Previous
From: ZHAOWANCHENG
Date:
Subject: Re: fixing pg_ctl with relative paths
Next
From: Peter Geoghegan
Date:
Subject: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)