> 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to