Re: Compression of full-page-writes

On Tue, Oct 8, 2013 at 10:07 PM, KONDO Mitsumasa
<kondo.mitsumasa@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