Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group