>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.fu...@gmail.com> wrote: > On Tue, May 27, 2014 at 12:57 PM, Rahila Syed <rahilasyed...@gmail.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 >
