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 00:12:29
Message-ID: dcc563d10810301712m1e266c48l9c2c6c4f5ccc40aa@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On Thu, Oct 30, 2008 at 6:03 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> writes:
>> Sounds kinda hand wavy to me.  If compressed file systems didn't give
>> you back what you gave them I couldn't imagine them being around for
>> very long.
>
> I don't know, NFS has lasted quite a while.
>
> So you tell me, I write 512 bytes of data to a compressed filesystem, how does
> it handle the torn page problem? Is it going to have to WAL log all data
> operations again?

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.

In response to

Responses

pgsql-general by date

Next:From: Greg SmithDate: 2008-10-31 01:18:08
Subject: Re: Decreasing WAL size effects
Previous:From: Gregory StarkDate: 2008-10-31 00:03:39
Subject: Re: Are there plans to add data compression feature to postgresql?

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