Re: Proposal of tunable fix for scalability of 8.4 - Mailing list pgsql-performance

From Matthew Wakeling
Subject Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id alpine.DEB.2.00.0903181346320.21772@aragorn.flymine.org
Whole thread Raw
In response to Re: Proposal of tunable fix for scalability of 8.4  ("Jignesh K. Shah" <J.K.Shah@Sun.COM>)
Responses Re: Proposal of tunable fix for scalability of 8.4  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-performance
On Wed, 18 Mar 2009, Jignesh K. Shah wrote:
> I thought about that.. Except without putting a restriction a huge queue will cause lot of time spent in manipulating
thelock 
> list every time. One more thing will be to maintain two list shared and exclusive and round robin through them for
everytime you 
> access the list so manipulation is low.. But the best thing is to allow flexibility to change the algorithm since
someworkloads 
> may work fine with one and others will NOT. The flexibility then allows to tinker for those already reaching the
limits.

Yeah, having two separate queues is the obvious way of doing this. It
would make most operations really trivial. Just wake everything in the
shared queue at once, and you can throw it away wholesale and allocate a
new queue. It avoids a whole lot of queue manipulation.

Matthew

--
 Software suppliers are trying to make their software packages more
 'user-friendly'.... Their best approach, so far, has been to take all
 the old brochures, and stamp the words, 'user-friendly' on the cover.
 -- Bill Gates

pgsql-performance by date:

Previous
From: "Jignesh K. Shah"
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4
Next
From: Ron Mayer
Date:
Subject: Re: Extremely slow intarray index creation and inserts.