Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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
-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
