On 2013-09-11 12:43:21 +0200, Andres Freund wrote: > On 2013-09-11 19:39:14 +0900, Fujii Masao wrote: > > * Benchmark > > pgbench -c 32 -j 4 -T 900 -M prepared > > scaling factor: 100 > > > > checkpoint_segments = 1024 > > checkpoint_timeout = 5min > > (every checkpoint during benchmark were triggered by checkpoint_timeout) > > > > * Result > > [tps] > > 1344.2 (full_page_writes = on) > > 1605.9 (compress) > > 1810.1 (off) > > > > [the amount of WAL generated during running pgbench] > > 4422 MB (on) > > 1517 MB (compress) > > 885 MB (off) > > > > [time required to replay WAL generated during running pgbench] > > 61s (on) .... 1209911 transactions were replayed, > > recovery speed: 19834.6 transactions/sec > > 39s (compress) .... 1445446 transactions were replayed, > > recovery speed: 37062.7 transactions/sec > > 37s (off) .... 1629235 transactions were replayed, > > recovery speed: 44033.3 transactions/sec > > ISTM for those benchmarks you should use an absolute number of > transactions, not one based on elapsed time. Otherwise the comparison > isn't really meaningful.
I really think we need to see recovery time benchmarks with a constant amount of transactions to judge this properly. Greetings, Andres Freund -- Andres Freund 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
