Re: Move PinBuffer and UnpinBuffer to atomics - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Move PinBuffer and UnpinBuffer to atomics
Date
Msg-id CAPpHfdskEG1BekGxedP3tfJFJsOuiJMBSfkRKm21+K5LQV9K5A@mail.gmail.com
Whole thread Raw
In response to Re: Move PinBuffer and UnpinBuffer to atomics  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: Move PinBuffer and UnpinBuffer to atomics  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Move PinBuffer and UnpinBuffer to atomics  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund <andres@anarazel.de> wrote:


On April 9, 2016 12:43:03 PM PDT, Andres Freund <andres@anarazel.de> wrote:
>On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote:
>> There are results with 5364b357 reverted.
>
>Crazy that this has such a negative impact. Amit, can you reproduce
>that? Alexander, I guess for r/w workload 5364b357 is a benefit on that
>machine as well?

How sure are you about these measurements?

I'm pretty sure.  I've retried it multiple times by hand before re-run the script.
 
Because there really shouldn't be clog lookups one a steady state is reached...

Hm... I'm also surprised. There shouldn't be clog lookups once hint bits are set.

I also tried to run perf top during pgbench and get some interesting results.

Without 5364b357:
   5,69%  postgres                 [.] GetSnapshotData
   4,47%  postgres                 [.] LWLockAttemptLock
   3,81%  postgres                 [.] _bt_compare
   3,42%  postgres                 [.] hash_search_with_hash_value
   3,08%  postgres                 [.] LWLockRelease
   2,49%  postgres                 [.] PinBuffer.isra.3
   1,58%  postgres                 [.] AllocSetAlloc
   1,17%  [kernel]                 [k] __schedule
   1,15%  postgres                 [.] PostgresMain
   1,13%  libc-2.17.so             [.] vfprintf
   1,01%  libc-2.17.so             [.] __memcpy_ssse3_back

With 5364b357:
  18,54%  postgres                 [.] GetSnapshotData
   3,45%  postgres                 [.] LWLockRelease
   3,27%  postgres                 [.] LWLockAttemptLock
   3,21%  postgres                 [.] _bt_compare
   2,93%  postgres                 [.] hash_search_with_hash_value
   2,00%  postgres                 [.] PinBuffer.isra.3
   1,32%  postgres                 [.] AllocSetAlloc
   1,10%  libc-2.17.so             [.] vfprintf

Very surprising.  It appears that after 5364b357, GetSnapshotData consumes more time.  But I can't see anything depending on clog buffers in GetSnapshotData code...
 
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [COMMITTERS] pgsql: Bloom index contrib module
Next
From: Alexander Korotkov
Date:
Subject: Re: [COMMITTERS] pgsql: Bloom index contrib module