Re: User concurrency thresholding: where do I look?

On Fri, 2007-07-20 at 16:57 -0400, Tom Lane wrote:
> "Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> writes:
> > What its saying is that there are holds/waits in trying to get locks
> > which are locked at Solaris user library levels called from the
> > postgresql functions:
> > For example both the following functions are hitting on the same mutex
> > lock 0x10059e280 in Solaris Library call:
> > postgres`AllocSetDelete+0x98
> > postgres`AllocSetAlloc+0x1c4
>
> That's a perfect example of the sort of useless overhead that I was
> complaining of just now in pgsql-patches. Having malloc/free use
> an internal mutex is necessary in multi-threaded programs, but the
> backend isn't multi-threaded. And yet, apparently you can't turn
> that off in Solaris.
>
> (Fortunately, the palloc layer is probably insulating us from malloc's
> performance enough that this isn't a huge deal. But it's annoying.)

There is one thing that the palloc layer doesn't handle: EState. All
other memory contexts have a very well chosen initial allocation that
prevents mallocs during low-medium complexity OLTP workloads.

EState is about 8300 bytes, so just above the large allocation limit.
This means that every time we request an EState, i.e. at least once per
statement we need to malloc() and then later free().

Would it be worth a special case in the palloc system to avoid having to
repeatedly issue external memory allocation calls?

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com