Re: Index AM change proposals, redux

"Martijn van Oosterhout" <kleptog@svana.org> writes:

> On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote:
>> Index compression is possible in many ways, depending upon the
>> situation. All of the following sound similar at a high level, but each
>> covers a different use case.
>
> True, but there is one significant difference:
>
>> * For Long, Similar data e.g. Text we can use Prefix Compression
>> * For Highly Non-Unique Data we can use Duplicate Compression
>> * Multi-Column Leading Value Compression - if you have a multi-column
>
> These are all not lossy and so are candidate to use on any b-tree even
> by default. They don't affect plan-construction materially, except
> perhaps in cost calculations. Given the index tuple overhead I don't
> see how you could lose.

The problem is that while it's easy to see what to do for text (and even then
perhaps not so easy in non-C locales) Postgres's extensibility makes it quite
tricky to see what to do from there.

Perhaps we need a btree procedure which takes two parameters, a "parent" and
"child" and returns a compressed value. There would have to be a second
procedure to decompress values given their full parent.

There are a lot of tricky bits here, like what do you do on leaf pages? You
have to be able to follow leaf pages down the chain without consulting their
"parent".

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!