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

Re: Are there plans to add data compression feature to postgresql?

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Are there plans to add data compression feature to postgresql?
Date: 2008-10-31 17:47:39
Message-ID: 87zlkkwtac.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-general
scott(dot)marlowe(at)gmail(dot)com ("Scott Marlowe") writes:
> I assume hardware failure rates are zero, until there is one.  Then I
> restore from a known good backup.  compressed file systems have little
> to do with that.

There's a way that compressed filesystems might *help* with a risk
factor, here...

By reducing the number of disk drives required to hold the data, you
may be reducing the risk of enough of them failing to invalidate the
RAID array.

If a RAID array is involved, where *some* failures may be silently
coped with, I could readily see this *improving* reliability, in most
cases.

This is at least *vaguely* similar to the way that aircraft have moved
from requiring rather large numbers of engines for cross-Atlantic
trips to requiring just 2.  

In the distant past, the engines were sufficiently unreliable that you
wanted to have at least 4 in order to be reasonably assured that you
could limp along with at least 2.

With increases in engine reliability, it's now considered preferable
to have *just* 2 engines, as having 4 means doubling the risk of there
being a failure.

Disk drives and jet engines are hardly the same thing, but I suspect
the analogy fits.
-- 
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/lisp.html
Why do they put Braille dots on the keypad of the drive-up ATM? 

In response to

Responses

pgsql-general by date

Next:From: Scott MarloweDate: 2008-10-31 18:27:27
Subject: Re: Connections getting stuck sending data to client
Previous:From: D. Dante LorensoDate: 2008-10-31 17:35:28
Subject: Re: Equivalent for AUTOINCREMENT?

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