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.1206061208410.5707@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 |
Hi, On Mon, 4 Jun 2012, Ants Aasma wrote: > On Mon, Jun 4, 2012 at 7:44 PM, Merlin Moncure <mmoncure@gmail.com> wrote: > I tried to keep it simple at first to find an answer to the question > if it's even worth trying before expending large effort on it. If > anyone with a multisocket machine would chip in, I'd love to know how > this patch handles on larger machines. I think the most interesting > workloads are read only loads with heavy buffer trashing but inside OS > memory. Select only pgbench with 32MB shared_buffers was withín error > margin, although slightly faster on my machine (Intel i2500K). The > workload that I used to demonstrate gain was an aggregated index scan > to minimise other overheads. I've quickly tested your lockfree-getbuffer.patch patch with the test case you provided and I barely see any improvement (2% at max) https://docs.google.com/open?id=0B7koR68V2nM1QVBxWGpZdW4wd0U tested with 24 core (48 ht cores, Xeon E7- 4807). Although the tps vs number of threads looks weird.... Cheers, 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 по дате отправления: