Re: Are there plans to add data compression feature to postgresql? - Mailing list pgsql-general

From Thomas Samson
Subject Re: Are there plans to add data compression feature to postgresql?
Date
Msg-id 4e96c6600810310739r2345d3d2y84393773793abaff@mail.gmail.com
Whole thread Raw
In response to Re: Are there plans to add data compression feature to postgresql?  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
On Fri, Oct 31, 2008 at 3:01 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
Scott Marlowe escribió:
> On Thu, Oct 30, 2008 at 7:37 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
> > Scott Marlowe escribió:
> >
> >> What is the torn page problem?  Note I'm no big fan of compressed file
> >> systems, but I can't imagine them not working with databases, as I've
> >> seen them work quite reliably under exhange server running a db
> >> oriented storage subsystem.  And I can't imagine them not being
> >> invisible to an application, otherwise you'd just be asking for
> >> trouble.
> >
> > Exchange, isn't that the thing that's very prone to corrupted databases?
> > I've heard lots of horror stories about that (and also about how you
> > have to defragment the database once in a while, so what kind of
> > database it really is?)
>
> Sure, bash Microsoft it's easy.   But it doesn't address the point, is
> a database safe on top of a compressed file system and if not, why?

I'm not bashing Microsoft.  I'm just saying that your example
application already shows signs that could, perhaps, be explained by the
hypothesis put forward by Greg -- that a compressed filesystem is more
prone to corruption.

Each added layer could lead to corruption/instability.

Yet, some people might be willing to try out  some of these layers
to enhance functionnality.

Postgresql already uses an OS, and even an fs! Why would it decide to not
recode it's own raw device handler ... like some serious db ;)

--
Thomas SAMSON
Simplicity does not precede complexity, but follows it.

pgsql-general by date:

Previous
From: "Grzegorz Jaśkiewicz"
Date:
Subject: Re: Equivalent for AUTOINCREMENT?
Next
From: Michael Hall
Date:
Subject: Re: Equivalent for AUTOINCREMENT?