| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort) |
| Date: | 2020-07-31 01:43:55 |
| Message-ID: | CAH2-WzmF329695BUkeVWMSgz642m2R=cHSM6YhkRLve_XupJSw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 30, 2020 at 6:39 PM James Coleman <jtc331(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-07-31 01:52:10 | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort) |
| Previous Message | ZHAOWANCHENG | 2020-07-31 01:42:42 | Re: fixing pg_ctl with relative paths |