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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)
Дата
Msg-id CAH2-WzmF329695BUkeVWMSgz642m2R=cHSM6YhkRLve_XupJSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)  (James Coleman <jtc331@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: ZHAOWANCHENG
Дата:
Сообщение: Re: fixing pg_ctl with relative paths
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)