Re: Fix overflow of nbatch
От | Konstantin Knizhnik |
---|---|
Тема | Re: Fix overflow of nbatch |
Дата | |
Msg-id | 125595a6-d7f4-4f44-b26b-c008e274dc4d@garret.ru обсуждение исходный текст |
Ответ на | Re: Fix overflow of nbatch (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Fix overflow of nbatch
|
Список | pgsql-hackers |
On 23/09/2025 6:11 PM, Tomas Vondra wrote: > Hi, > > I kept looking at this, and unfortunately the it seems a bit worse :-( > > Fixing the overflow is easy enough - adding the cast does the trick. > > But then there's the second issue I mentioned - the loop does not adjust > the hash_table_bytes. It updates the *space_allowed, but that's not what > the current_space/new_space formulas use. > > This breaks the "balancing" as the nbatch gets decreased until > > nbatch <= (work_mem / BLCKSZ) > > while the hash table "space_allowed" is increasing. This may result in > an *increased* memory usage :-( > > I also noticed the code does not clamp nbuckets properly as it should. > > > The question what to do about this. If we got this a week ago, I'd just > probably just revert a1b4f289, and then try again for PG19. After all, > the issue it meant to address is somewhat rare. > > But with 18 already stamped ... > > I've shared these findings with the rest of the RMT, I'll see what their > thoughts are. Of course, other opinions/suggestions are welcome. > > > regards > Hi Tomas, If you are going to investigate this problem more, can you also look at the related problem: https://www.postgresql.org/message-id/flat/52b94d5b-a135-489d-9833-2991a69ec623%40garret.ru#ebe4151f1d505bbcc32cf93b2e8a1936 I proposed the patch but got no feedback. Best regards, Konstantin
В списке pgsql-hackers по дате отправления: