Re: Are there plans to add data compression feature to postgresql? - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Are there plans to add data compression feature to postgresql?
Date
Msg-id 200810312205.m9VM5x219850@momjian.us
Whole thread Raw
In response to Re: Are there plans to add data compression feature to postgresql?  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List pgsql-general
Scott Marlowe wrote:
> On Thu, Oct 30, 2008 at 4:01 PM, Gregory Stark <stark@enterprisedb.com> wrote:
> > "Scott Marlowe" <scott.marlowe@gmail.com> writes:
> >
> >> I'm sure this makes for a nice brochure or power point presentation,
> >> but in the real world I can't imagine putting that much effort into it
> >> when compressed file systems seem the place to be doing this.
> >
> > I can't really see trusting Postgres on a filesystem that felt free to
> > compress portions of it. Would the filesystem still be able to guarantee that
> > torn pages won't "tear" across adjacent blocks? What about torn pages that
> > included hint bits being set?
>
> I can't see PostgreSQL noticing it. PostgreSQL hands the OS a 512byte
> block, the OS compresses it and it's brethren as the go to disk,
> uncompresses as they come out, and as long as what you put in is what
> you get back it shouldn't really matter.

The question is whether a write of 512 writes to disk blocks that hold
data for other parts of the file;  in such a case we might not have the
full page write copies of those pages to restore, and the compressed
operating system might not be able to guarantee that the other parts of
the file will be restored if only part of the 512 gets on disk.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: GEQO randomness?
Next
From: Dennis Brakhane
Date:
Subject: Re: Wildly erratic query performance