Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Full page writes improvement, code update

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: 2007-04-23 21:46:45
Message-ID: 200704231446.46126.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-23 21:48:57
Subject: Re: RETURN QUERY in PL/PgSQL?
Previous:From: Tom LaneDate: 2007-04-23 21:44:34
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2007-04-23 22:15:24
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Tom LaneDate: 2007-04-23 21:44:34
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group