On Thu, Dec 4, 2014 at 5:36 AM, Rahila Syed <rahilasyed.90@gmail.com> wrote: > The only scenario in which a user would not want to compress forcibly > written pages is when CPU utilization is high.
Or if they think the code to compress full pages is buggy.
Yeah, especially if in the future we begin to add support for other compression algorithm.
> But according to measurements > done earlier the CPU utilization of compress=’on’ and ‘off’ are not > significantly different.
If that's really true, we could consider having no configuration any time, and just compressing always. But I'm skeptical that it's actually true.
So am I. Data is the thing that matters for us.
Speaking of which, I have been working more on the set of patches to add support for this feature and attached are updated patches, with the following changes:
- Addition of a new GUC parameter wal_compression, being a complete switch to control compression of WAL. Default is off. We could extend this parameter later if we decide to add support for new algorithms or new modes, let's say a record-level compression. Parameter is PGC_POSTMASTER. We could make it PGC_SIGHUP but that would be better as a future optimization, and would need a new WAL record type similar to full_page_writes. (Actually, I see no urgency in making it SIGHUP..)
- full_page_writes is moved back to its original state
