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

From Andres Freund
Subject Re: Move PinBuffer and UnpinBuffer to atomics
Date
Msg-id 20151109221013.GH32209@alap3.anarazel.de
Whole thread Raw
In response to Re: Move PinBuffer and UnpinBuffer to atomics  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Responses Re: Move PinBuffer and UnpinBuffer to atomics  (Jesper Pedersen <jesper.pedersen@redhat.com>)
List pgsql-hackers
On 2015-11-09 11:54:59 -0500, Jesper Pedersen wrote:
> Hi,
> 
> On 11/06/2015 03:47 PM, Jesper Pedersen wrote:
> >>Did you initdb between tests? Pgbench -i? Restart the database?
> >
> >I didn't initdb / pgbench -i between the tests, so that it is likely it.
> >
> 
> Each graph has a full initdb + pgbench -i cycle now.

That looks about as we'd expect: the lock-free pinning doesn't matter
and ssynchronous commit is beneficial. I think our bottlenecks in write
workloads are sufficiently elsewhere that it's unlikely that buffer pins
make a lot of difference.

You could try a readonly pgbench workload (i.e. -S), to see whether a
difference is visible there. For a pgbench -S workload it's more likely
that you only see significant contention on larger machines. If you've a
workload that touches more cached buffers, it'd be visible earlier.

> I know, I have a brown paper bag somewhere.

Why? This looks as expected, and the issues from the previous run were
easy to make mistakes?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: storage/buffer/README docs about buffer replacement are out of date
Next
From: Amit Langote
Date:
Subject: Re: Getting sorted data from foreign server for merge join