Skip site navigation (1) Skip section navigation (2)

Re: User concurrency thresholding: where do I look?

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 (view raw or flat)
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

In response to

Responses

pgsql-performance by date

Next:From: Jignesh K. ShahDate: 2007-07-20 21:24:33
Subject: Re: User concurrency thresholding: where do I look?
Previous:From: Jignesh K. ShahDate: 2007-07-20 20:51:39
Subject: Re: User concurrency thresholding: where do I look?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group