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

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 小波 顾 <guxiaobo1982(at)hotmail(dot)com>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, chris(dot)ellis(at)shropshire(dot)gov(dot)uk, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Are there plans to add data compression feature to postgresql?
Date: 2008-10-31 10:50:29
Message-ID: dcc563d10810310350q1a474880m2f2e0b3d84eec30d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Oct 31, 2008 at 2:49 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> writes:
>
>> 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.
>
> Invisible under normal operation sure, but when something fails the
> consequences will surely be different and I can't see how you could make a
> compressed filesystem safe without a huge performance hit.

While I'm quite willing to concede that a crashed machine can cause
corruption in a compressed file system you wouldn't otherwise see, I'm
also willing to admit there are times, much like the OP was talking
about, where that's an acceptable loss, like Data Warehousing.

No way would I run a db for data that mattered on a compressed file system.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Patricio Mora 2008-10-31 11:00:53 Bad behaviour in Sun Cluster
Previous Message Scott Marlowe 2008-10-31 10:47:42 Re: Are there plans to add data compression feature to postgresql?