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

Reply via email to