Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
От | Sergey Koposov |
---|---|
Тема | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Дата | |
Msg-id | alpine.LRH.2.02.1205241912250.14366@calx046.ast.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: 9.2beta1, parallel queries, ReleasePredicateLocks,
CheckForSerializableConflictIn in the oprofile
|
Список | pgsql-hackers |
On Thu, 24 May 2012, Robert Haas wrote: > On Thu, May 24, 2012 at 1:42 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote: >> I guess there is nothing catastrophically wrong with that, but still I'm >> very suprised that you get severe locking problems (factor of two slow-down) >> when running parallel read-only transactions. > > Me, too. How many concurrent connections are you running, and does > your working set exceed shared_buffers? Can you provide a > self-contained reproducible test case? The last tests I've been doing were with 8 connections. And the working set is roughly 30Gig, which is ~ 3x the shared buffers. (but ~ 50% of RAM). Regarding the test-case, I'll try to see whether I can still observe the same slowing down if I chop the main table by a factor of few, so I can put the data somewhere for download. S ***************************************************** Sergey E. Koposov, PhD, Research Associate Institute of Astronomy, University of Cambridge Madingley road, CB3 0HA, Cambridge, UK Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/
В списке pgsql-hackers по дате отправления: