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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
