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

From Simon Riggs
Subject Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id 1237417654.3953.320.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Proposal of tunable fix for scalability of 8.4  (Matthew Wakeling <matthew@flymine.org>)
List pgsql-performance
On Wed, 2009-03-18 at 13:49 +0000, Matthew Wakeling wrote:
> 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
manipulatingthe lock 
> > 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.

Yes, that sounds good.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4
Next
From: Oleg Bartunov
Date:
Subject: Re: Extremely slow intarray index creation and inserts.