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.1206062017350.5707@calx046.ast.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile (Ants Aasma <ants@cybertec.at>) |
Ответы |
Re: 9.2beta1, parallel queries, ReleasePredicateLocks,
CheckForSerializableConflictIn in the oprofile
|
Список | pgsql-hackers |
On Wed, 6 Jun 2012, Ants Aasma wrote: > On Wed, Jun 6, 2012 at 2:27 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote: >> 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.... > > Was this the range scan on the test table? (sorry about the error in > the query, the x should really be id) In that case the results look > really suspicious. Yes, my fault partially, because without much thought I've put "value" instead of "x" in the script. Now after replacing it by "id" the tps are much smaller. Here is the tps vs nthreads I did test up to 10 threads on my 24 cpu system (I disabled HT though): https://docs.google.com/open?id=0B7koR68V2nM1Nk9OcWNJOTRrYVE Your patch clearly improve the situation (the peak tps is ~ 10% higher), but the general picture is the same: flattening of tps vs nthreads. 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 по дате отправления: