On Tue, Jul 26, 2016 at 9:02 AM, Chapman Flack <c...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers