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

On Fri, Oct 31, 2008 at 3:01 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com>wrote:

> Scott Marlowe escribió:
> > On Thu, Oct 30, 2008 at 7:37 PM, Alvaro Herrera
> > <alvherre(at)commandprompt(dot)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.