Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
От | Ants Aasma |
---|---|
Тема | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Дата | |
Msg-id | CA+CSw_uS1Sg=u-Q-B0QUGChwJs5_z4u7yx4YkvfbXbQj1oJP5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile (Sergey Koposov <koposov@ast.cam.ac.uk>) |
Ответы |
Re: 9.2beta1, parallel queries, ReleasePredicateLocks,
CheckForSerializableConflictIn in the oprofile
|
Список | pgsql-hackers |
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. My machine (4 cores, no ht, @ 4GHz, newer arch) peaked at 90tps with the stated configuration. Even when upping the shared_buffers and enabling indexonlyscan I didn't see more than about 540tps per thread. The test is designed to exercise buffer eviction, doing about 9800 buffer reads per transaction with 32MB of buffers. Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления: