On Sat, Jan 3, 2015 at 2:24 AM, Bruce Momjian <bruce@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 <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?
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