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

From Pierre Frédéric Caillaud
Subject Re: Table and Index compression
Date
Msg-id op.uyag4kzicke6l8@soyouz
Whole thread Raw
In response to Re: Table and Index compression  (Greg Stark <gsstark@mit.edu>)
Responses Re: Table and Index compression  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
> Also, I'm puzzled why it would the space increase would proportional
> to the amount of data and be more than 300 bytes. There's no reason it
> wouldn't be a small fixed amount. The ideal is you set aside one bit
> -- if the bit is set the rest is compressed and has to save at least
> one bit. If the bit is not set then the rest is uncompressed. Maximum
> bloat is 1-bit. In real systems it's more likely to be a byte or a
> word.
I'm working on cleaning the patch...
I added a field in PageHeader which contains :- 0 to indicate a non-compressed page- length of compressed data if
compressed
If compression gains nothing (ie gains less than 4K), the page is stored  
raw.
It seems that only pages having a PageHeader are handled by md.c, so it  
should work (am I mistaken ?)



pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: ECPG support for struct in INTO list
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: Split-up ECPG patches