| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, Vaibhav Jain <jainva(at)google(dot)com>, pgsql-hackers(at)postgresql(dot)org, Madhukar <madhukarprasad(at)google(dot)com>, Sangeetha Seshadri <sangsesh(at)google(dot)com> |
| Subject: | Re: Fix overflow of nbatch |
| Date: | 2025-10-08 19:16:06 |
| Message-ID: | CAAKRu_YF4P62gNezZyekhmNuV3k+Gy4Z7hWDJ2wYCYoCHNF-wg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 8, 2025 at 1:37 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> I have updated my patch to fix the mistakes above. I also noticed then
> that I wasn't doubling space_allowed in the loop but instead setting
> it to hash_table_bytes at the end. This doesn't produce a power of 2
> because we subtract skew_mcvs from the hash_table_bytes. So, we have
> to keep using space_allowed if we want a power of 2 in the end.
>
> I've changed my patch to do this, but this made me wonder if we want
> to be doing this or instead take hash_table_bytes at the end and round
> it up to a power of 2 and set space_allowed to that. If the skew
> hashtable is large, we may be allocating way more space_allowed than
> we need for new hash_table_bytes + skew hashtable buckets.
Oh wait, that doesn't make sense because each batch could have a skew hashtable.
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-10-08 19:20:23 | Re: Should we update the random_page_cost default value? |
| Previous Message | Tomas Vondra | 2025-10-08 19:12:37 | Re: Should we update the random_page_cost default value? |