On Fri, Oct 4, 2013 at 10:49 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Mon, Sep 30, 2013 at 1:55 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> On Mon, Sep 30, 2013 at 1:27 PM, KONDO Mitsumasa >>> <kondo.mitsum...@lab.ntt.co.jp> wrote: >>>> Hi Fujii-san, >>>> >>>> >>>> (2013/09/30 12:49), Fujii Masao wrote: >>>>> On second thought, the patch could compress WAL very much because I used >>>>> pgbench. >>>>> >>>>> I will do the same measurement by using another benchmark. >>>> >>>> If you hope, I can test this patch in DBT-2 benchmark in end of this week. >>>> I will use under following test server. >>>> >>>> * 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 >>> >>> Yep, please! It's really helpful! >> >> I think it will be useful if you can get the data for 1 and 2 threads >> (may be with pgbench itself) as well, because the WAL reduction is >> almost sure, but the only thing is that it should not dip tps in some >> of the scenarios. > > Here is the measurement result of pgbench with 1 thread. > > scaling factor: 100 > query mode: prepared > number of clients: 1 > number of threads: 1 > duration: 900 s > > WAL Volume > - 1344 MB (full_page_writes = on) > - 349 MB (compress) > - 78 MB (off) > > TPS > 117.369221 (on) > 143.908024 (compress) > 163.722063 (off)
This data is good. I will check if with the help of my old colleagues, I can get the performance data on m/c where we have tried similar idea. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers