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.
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? |