On Mon, Sep 30, 2013 at 5:28 PM, Bernd Helmle <maili...@oopsware.de> wrote: > > > --On 30. September 2013 19:00:06 +0200 Andres Freund > <and...@2ndquadrant.com> wrote: > >>> HEAD (default): >>> >>> tps = 181738.607247 (including connections establishing) >>> tps = 182665.993063 (excluding connections establishing) >>> >>> HEAD (padding + 16 partitions + your lwlocks patch applied): >>> >>> tps = 269328.259833 (including connections establishing) >>> tps = 270685.666091 (excluding connections establishing) >>> >>> So, still an improvement but far away from what you got. Do you have some >>> other tweaks in your setup? >> >> >> The only relevant setting changed was -c shared_buffers=1GB, no other >> patches applied. At which scale did you pgbench -i? > > > I've used a scale factor of 10 (i recall you've mentioned using the same > upthread...). > > Okay, i've used 2GB shared buffers, repeating with your setting i get a far > more noticable speedup:
If Andres's patch passes muster it may end up causing us to re-evaluate practices for the shared buffer setting. I was trying to optimize buffer locking in the clock sweep using a different approach and gave up after not being able to find useful test cases to demonstrate an improvement. The main reason for this is that clock sweep issues are masked by contention in the buffer mapping lwlocks (as you guys noted). I *do* think clock sweep contention comes out in some production workloads but so far have been elusive to produce in synthetic testing. Ditto buffer pin contention (this has been documented). So I'm very excited about this patch. Right now in servers I configure (even some very large ones) I set shared buffers to max 2gb for various reasons. Something tells me that's about to change. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
