Re: User concurrency thresholding: where do I look?
От | Simon Riggs |
---|---|
Тема | Re: User concurrency thresholding: where do I look? |
Дата | |
Msg-id | 1185205663.4284.249.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: User concurrency thresholding: where do I look? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: User concurrency thresholding: where do I look?
Re: User concurrency thresholding: where do I look? |
Список | pgsql-performance |
On Mon, 2007-07-23 at 10:54 -0400, Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: > > I looked at this last May and my notes say "ExecutorState". I guess that > > was wrong, but my analysis showed there was a single malloc of 8228 > > bytes happening once per query during my tests. > > Well, if you can track down where it's coming from, we could certainly > hack the containing context's parameters. But EState's not it. Well, I discover there is an allocation of 8232 (inflation...) made once per statement by a memory context called... ExecutorState. Still not sure exactly which allocation this is, but its definitely once per statement on pgbench, which should narrow it down. Plan, query etc? I don't see a way to hack the allocation, since the max chunk size is 8K. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-performance по дате отправления: