Re: Proposal of tunable fix for scalability of 8.4

Поиск
Список
Период
Сортировка
От Matthew Wakeling
Тема Re: Proposal of tunable fix for scalability of 8.4
Дата
Msg-id alpine.DEB.2.00.0903181346320.21772@aragorn.flymine.org
обсуждение исходный текст
Ответ на Re: Proposal of tunable fix for scalability of 8.4  ("Jignesh K. Shah" <J.K.Shah@Sun.COM>)
Ответы Re: Proposal of tunable fix for scalability of 8.4  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jignesh K. Shah"
Дата:
Сообщение: Re: Proposal of tunable fix for scalability of 8.4
Следующее
От: Ron Mayer
Дата:
Сообщение: Re: Extremely slow intarray index creation and inserts.