On Tue, Oct 8, 2013 at 10:07 PM, KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp> wrote: > Hi, > > I tested dbt-2 benchmark in single instance and synchronous replication.
Thanks! > Unfortunately, my benchmark results were not seen many differences... > > > * Test server > Server: HP Proliant DL360 G7 > CPU: Xeon E5640 2.66GHz (1P/4C) > Memory: 18GB(PC3-10600R-9) > Disk: 146GB(15k)*4 RAID1+0 > RAID controller: P410i/256MB > > * Result > ** Single instance** > | NOTPM | 90%tile | Average | S.Deviation > ------------+-----------+-------------+---------+------------- > no-patched | 3322.93 | 20.469071 | 5.882 | 10.478 > patched | 3315.42 | 19.086105 | 5.669 | 9.108 > > > ** Synchronous Replication ** > | NOTPM | 90%tile | Average | S.Deviation > ------------+-----------+-------------+---------+------------- > no-patched | 3275.55 | 21.332866 | 6.072 | 9.882 > patched | 3318.82 | 18.141807 | 5.757 | 9.829 > > ** Detail of result > http://pgstatsinfo.projects.pgfoundry.org/DBT-2_Fujii_patch/ > > > I set full_page_write = compress with Fujii's patch in DBT-2. But it does > not > seems to effect for eleminating WAL files. Could you let me know how much WAL records were generated during each benchmark? I think that this benchmark result clearly means that the patch has only limited effects in the reduction of WAL volume and the performance improvement unless the database contains highly-compressible data like pgbench_accounts.filler. But if we can use other compression algorithm, maybe we can reduce WAL volume very much. I'm not sure what algorithm is good for WAL compression, though. It might be better to introduce the hook for compression of FPW so that users can freely use their compression module, rather than just using pglz_compress(). Thought? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers