Re: User concurrency thresholding: where do I look?
От | Simon Riggs |
---|---|
Тема | Re: User concurrency thresholding: where do I look? |
Дата | |
Msg-id | 1185213053.4284.278.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: User concurrency thresholding: where do I look? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Mon, 2007-07-23 at 12:35 -0400, Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: > > 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? > > Are you working with stock sources? The only allocation exceeding 1K > that I can see during pgbench is BTScanOpaqueData, which is 6600 bytes. > (Checked by setting a conditional breakpoint on AllocSetAlloc.) The > path that allocates a single-chunk block is never taken at all. I do have the bitmap patch currently applied, but it doesn't touch that part of the code. (gdb) p size $1 = 8232 (gdb) p sizeof(int) $2 = 4 (gdb) p sizeof(BTScanPosData) $3 = 4104 Since my notes say I got 8228 last year, seems reasonable. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-performance по дате отправления: