On Sat, Mar 26, 2011 at 5:51 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Mar 26, 2011 at 12:41 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> Is it? Sync rep requires fsync on the standby. If you then explicitly >> turn off fsync on the standby then it has a performance impact, as >> documented. > > Actually, it doesn't, now that you fixed this. Before: > > [rhaas@office ~]$ pgbench -T 10 > starting vacuum...end. > transaction type: TPC-B (sort of) > scaling factor: 25 > query mode: simple > number of clients: 1 > number of threads: 1 > duration: 10 s > number of transactions actually processed: 27 > tps = 0.099386 (including connections establishing) > tps = 0.099389 (excluding connections establishing) > [rhaas@office ~]$ pgbench -T 10 > starting vacuum...end. > transaction type: TPC-B (sort of) > scaling factor: 25 > query mode: simple > number of clients: 1 > number of threads: 1 > duration: 10 s > number of transactions actually processed: 425 > tps = 42.442185 (including connections establishing) > tps = 42.468972 (excluding connections establishing) > > The first one - run with code from a few weeks ago - hung up on the > 27th transaction and was stuck there until the next checkpoint > completed. The second one was run with the latest code and no longer > hangs - and in fact it's now faster than running with fsync=on, > exactly as one would expect. Or at least as *I* expected.
Are the master and standby on same system or are they separated by a network? I'm surprised that a network roundtrip takes less time than the backend takes to mark clog and then queue for the SyncRepLock. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
