| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> |
| Cc: | 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-20 20:57:34 |
| Message-ID: | 15343.1184965054@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"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.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jignesh K. Shah | 2007-07-20 21:24:33 | Re: User concurrency thresholding: where do I look? |
| Previous Message | Jignesh K. Shah | 2007-07-20 20:51:39 | Re: User concurrency thresholding: where do I look? |