Re: Table and Index compression - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Table and Index compression
Date
Msg-id 407d949e0908070459l5a3e855cu2ed146f7e18c57bc@mail.gmail.com
Whole thread Raw
In response to Re: Table and Index compression  (Sam Mason <sam@samason.me.uk>)
Responses Re: Table and Index compression  (Greg Stark <gsstark@mit.edu>)
Re: Table and Index compression  (Sam Mason <sam@samason.me.uk>)
Re: Table and Index compression  (Pierre Frédéric Caillaud<lists@peufeu.com>)
List pgsql-hackers
On Fri, Aug 7, 2009 at 12:48 PM, Sam Mason<sam@samason.me.uk> wrote:
>> Well most users want compression for the space savings. So running out
>> of space sooner than without compression when most of the space is
>> actually unused would disappoint them.
>
> Note, that as far as I can tell for a filesystems you only need to keep
> enough reserved for the amount of uncompressed dirty buffers you have in
> memory.  As space runs out in the filesystem all that happens is that
> the amount of (uncompressed?) dirty buffers you can safely have around
> decreases.

And when it drops to zero?

> In PG's case, it would seem possible to do the compression and then
> check to see if the resulting size is greater than 4kB.  If it is you
> write into the 4kB page size and write uncompressed data.  Upon reading
> you do the inverse, if it's 4kB then no need to decompress.  I believe
> TOAST does this already.

It does, as does gzip and afaik every compression system.

--
greg
http://mit.edu/~gsstark/resume.pdf


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Split-up ECPG patches
Next
From: Greg Stark
Date:
Subject: Re: Table and Index compression