| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Taylor Vesely <tvesely(at)pivotal(dot)io>, Adam Lee <ali(at)pivotal(dot)io>, Melanie Plageman <mplageman(at)pivotal(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Memory-Bounded Hash Aggregation |
| Date: | 2020-02-05 19:56:11 |
| Message-ID: | e1e198ec13b4831f4a073def0f7751af0b047c9b.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2020-02-04 at 18:10 +0200, Heikki Linnakangas wrote:
> I'd love to change the LogicalTape API so that you could allocate
> and
> free tapes more freely. I wrote a patch to do that, as part of
> replacing
> tuplesort.c's polyphase algorithm with a simpler one (see [1]), but
> I
> never got around to committing it. Maybe the time is ripe to do that
> now?
It's interesting that you wrote a patch to pause the tapes a while ago.
Did it just fall through the cracks or was there a problem with it?
Is pause/resume functionality required, or is it good enough that
rewinding a tape frees the buffer, to be lazily allocated later?
Regarding the API, I'd like to change it, but I'm running into some
performance challenges when adding a layer of indirection. If I apply
the very simple attached patch, which simply makes a separate
allocation for the tapes array, it seems to slow down sort by ~5%.
Regards,
Jeff Davis
| Attachment | Content-Type | Size |
|---|---|---|
| tapes-indirection.patch | text/x-patch | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-02-05 20:18:08 | Re: widen vacuum buffer counters |
| Previous Message | Pavel Stehule | 2020-02-05 19:18:08 | Re: [Proposal] Global temporary tables |