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

From Bruce Momjian
Subject Re: Compression of full-page-writes
Date
Msg-id 20150102172458.GF22217@momjian.us
Whole thread Raw
In response to Re: Compression of full-page-writes  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Compression of full-page-writes
Re: Compression of full-page-writes
List pgsql-hackers
On Fri, Jan  2, 2015 at 02:18:12PM -0300, Claudio Freire wrote:
> On Fri, Jan 2, 2015 at 2:11 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> , I now see the compression patch as something that has negatives, so
> >> has to be set by the user, and only wins in certain cases.  I am
> >> disappointed, and am trying to figure out how this became such a
> >> marginal win for 9.5.  :-(
> >
> > I find the notion that a multi digit space reduction is a "marginal win"
> > pretty ridiculous and way too narrow focused. Our WAL volume is a
> > *significant* problem in the field. And it mostly consists out of FPWs
> > spacewise.
> 
> One thing I'd like to point out, is that in cases where WAL I/O is an
> issue (ie: WAL archiving), usually people already compress the
> segments during archiving. I know I do, and I know it's recommended on
> the web, and by some consultants.
> 
> So, I wouldn't want this FPW compression, which is desirable in
> replication scenarios if you can spare the CPU cycles (because of
> streaming), adversely affecting WAL compression during archiving.

To be specific, desirable in streaming replication scenarios that don't
use SSL compression.  (What percentage is that?)  It is something we
should mention in the docs for this feature?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Publish autovacuum informations
Next
From: Andres Freund
Date:
Subject: Re: Misaligned BufferDescriptors causing major performance problems on AMD