Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Compression of full-page-writes
Date
Msg-id CAA4eK1JVn89xNT295ngKu8tab-Uu-A+CACNkYj8AnfVuCh1RwA@mail.gmail.com
Whole thread Raw
In response to Re: Compression of full-page-writes  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
Re: Compression of full-page-writes  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Dec 8, 2014 at 3:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On 8 December 2014 at 11:46, Michael Paquier <michael.paquier@gmail.com> wrote:
> > I don't really like those new names, but I'd prefer
> > wal_compression_level if we go down that road with 'none' as default
> > value. We may still decide in the future to support compression at the
> > record level instead of context level, particularly if we have an API
> > able to do palloc_return_null_at_oom, so the idea of WAL compression
> > is not related only to FPIs IMHO.
>
> We may yet decide, but the pglz implementation is not effective on
> smaller record lengths. Nor has any testing been done to show that is
> even desirable.
>

It's even much worse for non-compressible (or less-compressible)
WAL data.  I am not clear here that how a simple on/off switch
could address such cases because the data could be sometimes
dependent on which table user is doing operations (means schema or
data in some tables are more prone for compression in which case
it can give us benefits).  I think may be we should think something on
lines what Robert has touched in one of his e-mails (context-aware
compression strategy).


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: moving from contrib to bin
Next
From: Peter Geoghegan
Date:
Subject: Re: moving from contrib to bin