| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Trouble with hashagg spill I/O pattern and costing |
| Date: | 2020-05-21 19:17:39 |
| Message-ID: | 20200521191739.hi7g7rhhv6txxrwc@development |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 21, 2020 at 12:04:19PM -0700, Jeff Davis wrote:
>On Thu, 2020-05-21 at 20:54 +0200, Tomas Vondra wrote:
>> The last column is master with the tlist tweak alone - it's better
>> than
>> hashagg on master alone, but it's not nearly as good as with both
>> tlist
>> and prealloc patches.
>
>Right, I certainly think we should do the prealloc change, as well.
>
>I'm tweaking the patch to be a bit more flexible. I'm thinking we
>should start the preallocation list size ~8 and then double it up to
>~128 (depending on your results). That would reduce the waste in case
>we have a large number of small partitions.
>
You're reading my mind ;-)
I don't think 128 is necessarily the maximum we should use - it's just
that I haven't tested higher values. I wouldn't be surprised if higher
values made it a bit faster. But we can test and tune that, I agree with
growing the number of pre-allocted blocks over time.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2020-05-21 19:40:23 | Re: Trouble with hashagg spill I/O pattern and costing |
| Previous Message | Tomas Vondra | 2020-05-21 19:13:18 | Re: Trouble with hashagg spill I/O pattern and costing |