Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
От | Jeff Davis |
---|---|
Тема | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
Дата | |
Msg-id | 1407485792.15301.64.camel@jeff-desktop обсуждение исходный текст |
Ответ на | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: 9.5: Better memory accounting, towards memory-bounded
HashAgg
Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
Список | pgsql-hackers |
On Wed, 2014-08-06 at 11:43 -0400, Robert Haas wrote: > Comparing the median times, that's about a 3% regression. For this > particular case, we might be able to recapture that by replacing the > bespoke memory-tracking logic in tuplesort.c with use of this new > facility. I'm not sure whether there are other cases that we might > also want to test; I think stuff that runs all on the server side is > likely to show up problems more clearly than pgbench. Maybe a > PL/pgsql loop that does something allocation-intensive on each > iteration, for example, like parsing a big JSON document. I wasn't able to reproduce your results on my machine. At -s 300, with maintenance_work_mem set high enough to do internal sort, it took about 40s and I heard some disk activity, so I didn't think it was a valid result. I went down to -s 150, and it took around 5.3s on both master and memory-accounting. Either way, it's better to be conservative. Attached is a version of the patch with opt-in memory usage tracking. Child contexts inherit the setting from their parent. Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: