Re: Compression of full-page-writes

>Thanks for extending and revising the FPW-compress patch! Could you add
>your patch into next CF?
Sure. I will make improvements and add it to next CF.

>Isn't it worth measuring the recovery performance for each compression
>algorithm?
Yes I will post this soon.

On Wed, May 28, 2014 at 8:04 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Tue, May 27, 2014 at 12:57 PM, Rahila Syed <rahilasyed(dot)90(at)gmail(dot)com>
> wrote:
> > Hello All,
> >
> > 0001-CompressBackupBlock_snappy_lz4_pglz extends patch on compression of
> > full page writes to include LZ4 and Snappy . Changes include making
> > "compress_backup_block" GUC from boolean to enum. Value of the GUC can be
> > OFF, pglz, snappy or lz4 which can be used to turn off compression or set
> > the desired compression algorithm.
> >
> > 0002-Support_snappy_lz4 adds support for LZ4 and Snappy in PostgreSQL. It
> > uses Andres’s patch for getting Makefiles working and has a few wrappers
> to
> > make the function calls to LZ4 and Snappy compression functions and
> handle
> > varlena datatypes.
> > Patch Courtesy: Pavan Deolasee
>
> Thanks for extending and revising the FPW-compress patch! Could you add
> your patch into next CF?
>
> > Also, compress_backup_block GUC needs to be merged with full_page_writes.
>
> Basically I agree with you because I don't want to add new GUC very
> similar to
> the existing one.
>
> But could you imagine the case where full_page_writes = off. Even in this
> case,
> FPW is forcibly written only during base backup. Such FPW also should be
> compressed? Which compression algorithm should be used? If we want to
> choose the algorithm for such FPW, we would not be able to merge those two
> GUCs. IMO it's OK to always use the best compression algorithm for such FPW
> and merge them, though.
>
> > Tests use JDBC runner TPC-C benchmark to measure the amount of WAL
> > compression ,tps and response time in each of the scenarios viz .
> > Compression = OFF , pglz, LZ4 , snappy ,FPW=off
>
> Isn't it worth measuring the recovery performance for each compression
> algorithm?
>
> Regards,
>
> --
> Fujii Masao
>