| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Adam Lee <ali(at)pivotal(dot)io> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Taylor Vesely <tvesely(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 18:26:17 |
| Message-ID: | 16536709b8b3e7d07d6d58f598e9d60ef6531b97.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2020-02-04 at 18:42 +0800, Adam Lee wrote:
> The minheap looks good, have you tested the performance and aggregate
> validation?
Not sure exactly what you mean, but I tested the min heap with both
Sort and HashAgg and it performs well.
> About the "Cap the size of the LogicalTapeSet's freelist" and "Don't
> bother tracking free space for HashAgg at all" you mentioned in last
> mail, I suppose these two options will lost the disk space saving
> benefit since some blocks are not reusable then?
No freelist at all will, of course, leak the blocks and not reuse the
space.
A capped freelist is not bad in practice; it seems to still work as
long as the cap is reasonable. But it feels too arbitrary, and could
cause unexpected leaks when our assumptions change. I think a minheap
just makes more sense unless the freelist just becomes way too large.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2020-02-05 18:37:15 | Re: Memory-Bounded Hash Aggregation |
| Previous Message | Robert Haas | 2020-02-05 18:09:48 | Re: Is custom MemoryContext prohibited? |