From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Are there plans to add data compression feature to postgresql? |
Date: | 2008-10-31 17:08:52 |
Message-ID: | 877i7oheu3.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> writes:
> On Fri, 31 Oct 2008 08:49:56 +0000
> Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>> 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.
>
> Pardon my naiveness but I can't get why compression and data
> integrity should be always considered clashing factors.
Well the answer was in the next paragraph of my email, the one you've clipped
out here.
> DB operation are supposed to be atomic if fsync actually does what
> it is supposed to do.
> So you'd have coherency assured by proper execution of "fsync" going
> down to all HW levels before it reach permanent storage.
fsync lets the application know when the data has reached disk. Once it
returns you know the data on disk is coherent. What we're talking about is
what to do if the power fails or the system crashes before that happens.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Murphy | 2008-10-31 17:34:20 | Re: perl-DBD-Pg package for CentOS 5? |
Previous Message | Joao Ferreira | 2008-10-31 16:26:48 | Re: perl-DBD-Pg package for CentOS 5? |