Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
От | Jeff Davis |
---|---|
Тема | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
Дата | |
Msg-id | 1416296354.2998.157.camel@jeff-desktop обсуждение исходный текст |
Ответ на | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
|
Список | pgsql-hackers |
On Mon, 2014-11-17 at 18:04 +0100, Andres Freund wrote: > That's quite possibly one culprit for the slowdown. Right now one > AllocSetContext struct fits precisely into three cachelines. After your > change it doesn't anymore. Thank you! I made the same mistake as Tomas: I saw that MemoryContextData went to 64 bytes and thought "that should be fine" while ignoring AllocSetContext. I did some tests in the past between a version of my patch that made MemoryContextData 72 bytes and one that made it 64 bytes, but I may have neglected to test against the original 56 byte version. I'm still not able to test to see if this is the real problem, but it seems best to eliminate it anyway. > Consider not counting memory in bytes but blocks and adding it directly > after the NodeTag. That'd leave the size the same as right now. I can also just move isReset there, and keep mem_allocated as a uint64. That way, if I find later that I want to track the aggregated value for the child contexts as well, I can split it into two uint32s. I'll hold off any any such optimizations until I see some numbers from HashAgg though. Attached new version. Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: