| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: User concurrency thresholding: where do I look? |
| Date: | 2007-07-23 14:39:16 |
| Message-ID: | 1185201556.4284.243.camel@ebony.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, 2007-07-23 at 10:11 -0400, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > EState is about 8300 bytes,
>
> What?
>
> (gdb) p sizeof(EState)
> $1 = 112
>
> This is on a 32-bit machine, but even on 64-bit it wouldn't be more than
> double that.
>
> > Would it be worth a special case in the palloc system to avoid having to
> > repeatedly issue external memory allocation calls?
>
> The appropriate hack would be to change the AllocSetContextCreate
> initial-size parameter for the containing context. But I really have
> no idea what you're on about.
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.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-07-23 14:54:58 | Re: User concurrency thresholding: where do I look? |
| Previous Message | Tom Lane | 2007-07-23 14:11:41 | Re: User concurrency thresholding: where do I look? |