On Sat, Jan 3, 2015 at 2:24 AM, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Jan 2, 2015 at 02:18:12PM -0300, Claudio Freire wrote: >> On Fri, Jan 2, 2015 at 2:11 PM, Andres Freund <and...@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?
Even if SSL is used in replication, FPW compression is useful. It can reduce the amount of I/O in the standby side. Sometimes I've seen walreceiver's I/O had become a performance bottleneck especially in synchronous replication cases. FPW compression can be useful for those cases, for example. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
