Hackers,
> Writing lots of additional code simply to remove a parameter that
> *might* be mis-interpreted doesn't sound useful to me, especially when
> bugs may leak in that way. My take is that this is simple and useful
> *and* we have it now; other ways don't yet exist, nor will they in time
> for 8.3.
How about naming the parameter wal_compressable? That would indicate pretty
clearly that the parameter is intended to be used with wal_compress and
nothing else.
However, I do agree with Andreas that anything which adds to WAL volume, even
3%, seems like going in the wrong direction. We already have higher log
output than any comparable database (higher than InnoDB by 3x) and we should
be looking for output to trim as well as compression.
So the relevant question is whether the patch in its current form provides
enough benefit to make it worthwhile for 8.3, or whether we should wait for
8.4. Questions:
1) is there any throughput benefit for platforms with fast CPU but contrained
I/O (e.g. 2-drive webservers)? Any penalty for servers with plentiful I/O?
2) Will this patch make attempts to reduce WAL volume in the future
significantly harder?
3) How is this better than command-line compression for log-shipping? e.g.
why do we need it in the database?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
