On Thu, Nov 27, 2014 at 11:42 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-11-27 13:00:57 +0900, Michael Paquier wrote:
>> This is backward-incompatible in the fact that forcibly-written FPWs
>> would be compressed all the time, even if FPW is set to off. The
>> documentation of the previous patches also mentioned that images are
>> compressed only if this parameter value is switched to compress.
>
> err, "backward incompatible"? I think it's quite useful to allow
> compressing newpage et. al records even if FPWs aren't required for the
> hardware.
Incorrect words. This would enforce a new behavior on something that's
been like that for ages even if we have a switch to activate it.
> One thing Heikki brought up somewhere, which I thought to be a good
> point, was that it might be worthwile to forget about compressing FDWs
> themselves, and instead compress entire records when they're large. I
> think that might just end up being rather beneficial, both from a code
> simplicity and from the achievable compression ratio.
Indeed, that would be quite simple to do. Now determining an ideal cap
value is tricky. We could always use a GUC switch to control that but
that seems sensitive to set, still we could have a recommended value
in the docs found after looking at some average record size using the
regression tests.
--
Michael