From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Move PinBuffer and UnpinBuffer to atomics |
Date: | 2015-11-10 17:03:11 |
Message-ID: | 5642234F.6070501@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 11/09/2015 05:10 PM, Andres Freund wrote:
>> 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.
>
Using
https://commitfest.postgresql.org/7/373/
shows that the CLog queue is max'ed out on the number of client connections.
> 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.
>
Yeah, basically no difference between the 4 -S runs on this setup.
>> 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?
>
I should have known to do the full cycle of initdb / pgbench -i in the
first place.
Best regards,
Jesper
Attachment | Content-Type | Size |
---|---|---|
image/png | 16.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-11-10 17:03:41 | Re: [COMMITTERS] pgsql: Translation updates |
Previous Message | Magnus Hagander | 2015-11-10 16:59:00 | Re: Uh-oh: documentation PDF output no longer builds in HEAD |