On Tue, Jul 26, 2016 at 9:02 AM, Chapman Flack <chap@anastigmatix.net> wrote:
> On 07/25/16 22:09, Michael Paquier wrote:
>
>> This is over-complicating things for little gain. The new behavior of
>> filling in with zeros the tail of a segment makes things far better
>> when using gzip in archive_command.
>
> Then how about filling with actual zeros, instead of with mostly-zeros
> as is currently done? That would work just as well for gzip, and would
> not sacrifice the ability to do 100x better than gzip.
>
There is a flag XLP_BKP_REMOVABLE for the purpose of ignoring empty
blocks, any external tool/'s relying on it can break, if make
everything zero. Now, it might be possible to selectively initialize
the fields that doesn't harm the methodology for archive you are using
considering there is no other impact of same in code. However, it
doesn't look to be a neat way to implement the requirement. In
general, if you have a very low WAL activity, then the final size of
compressed WAL shouldn't be much even if you use gzip. It seems your
main concern is that the size of WAL even though not high, but it is
more than what you were earlier getting for your archive data. I
think that is a legitimate concern, but I don't see much options apart
for providing some selective way to not initialize everything in WAL
page headers or have some tool like pg_lesslog that can be shipped as
part of contrib module. I am not sure whether your use case is
important enough to proceed with one of those options or may be
consider some another approach. Does any body else see the use case
reported by Chapman important enough that we try to have some solution
for it in-core?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com