On Wed, Aug 7, 2013 at 4:18 PM, Kevin Grittner <kgri...@ymail.com> wrote: > Thom Brown <t...@linux.com> wrote: > >> pgbench -j 80 -c 80 -T 3600 >> >> 269e78: 606.268013 >> 8800d8: 779.583129
I have also been running some tests and - as yet - they are inconclusive. What I can say about them so far is that - at times - they agree with these results and do show a performance hit. I took the settings as posted and adjusted them slightly for my much lower-powered personal laptop, changing checkpoint_completion_target to 1.0 and checkpoint_timeout to 1min. I am testing with the latest git HEAD, turning fallocate support on and off by editing xlog.c directly. Furthermore, before each run I would try to reduce the number of existing WAL files by making a "pre" run with checkpoint_segments = 3 before changing it to 32. For reasons I don't entirely understand, when WAL files are being created (rather than recycled) I found a performance hit, but when they were being recycled I got a slight performance gain (this may be due to reduced fragmentation) but the gain was never more than 10% and frequently less than that. I can't explain - yet (if ever!) - why my initial tests (and many of those done subsequently) showed improvement - it may very well have something to do with how the code interacts with these settings. -- Jon -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
