From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Move PinBuffer and UnpinBuffer to atomics |
Date: | 2015-11-09 22:10:13 |
Message-ID: | 20151109221013.GH32209@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-11-10 00:35:01 | Re: Getting sorted data from foreign server for merge join |
Previous Message | Andres Freund | 2015-11-09 22:04:12 | storage/buffer/README docs about buffer replacement are out of date |