Re: Proposal of tunable fix for scalability of 8.4
От | Kevin Grittner |
---|---|
Тема | Re: Proposal of tunable fix for scalability of 8.4 |
Дата | |
Msg-id | 49BA5960.EE98.0025.0@wicourts.gov обсуждение исходный текст |
Ответ на | Re: Proposal of tunable fix for scalability of 8.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal of tunable fix for scalability of 8.4
Re: Proposal of tunable fix for scalability of 8.4 |
Список | pgsql-performance |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I think that changing the locking behavior is attacking the problem >> at the wrong level anyway. > > Right. By the time a patch here could have any effect, you've > already lost the game --- having to deschedule and reschedule a > process is a large cost compared to the typical lock hold time for > most LWLocks. So it would be better to look at how to avoid > blocking in the first place. That's what motivated my request for a profile of the "80 clients with zero wait" case. If all data access is in RAM, why can't 80 processes keep 64 threads (on 8 processors) busy? Does anybody else think that's an interesting question, or am I off in left field here? -Kevin
В списке pgsql-performance по дате отправления: