Re: Move PinBuffer and UnpinBuffer to atomics
| От | Alexander Korotkov |
|---|---|
| Тема | Re: Move PinBuffer and UnpinBuffer to atomics |
| Дата | |
| Msg-id | CAPpHfdvcQnPQU3_KwQHNmngsQFfihx6b21KsW6LACnHhoXW_bQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Move PinBuffer and UnpinBuffer to atomics (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: Move PinBuffer and UnpinBuffer to atomics
|
| Список | pgsql-hackers |
On Tue, Apr 5, 2016 at 10:26 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
On Mon, Apr 4, 2016 at 2:28 PM, Andres Freund <andres@anarazel.de> wrote:Hm, interesting. I suspect that's because of the missing backoff in my
experimental patch. If you apply the attached patch ontop of that
(requires infrastructure from pinunpin), how does performance develop?
I have applied this patch also, but still results are same, I mean around 550,000 with 64 threads and 650,000 with 128 client with lot of fluctuations..128 client (head+0001-WIP-Avoid-the-use-of-a-separate-spinlock-to-protect +pinunpin-cas-9+backoff)run1 645769run2 643161run3 285546run4 289421run5 630772run6 284363
Could the reason be that we're increasing concurrency for LWLock state atomic variable by placing queue spinlock there?
But I wonder why this could happen during "pgbench -S", because it doesn't seem to have high traffic of exclusive LWLocks.
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: