Re: prefix btree implementation - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: prefix btree implementation
Date
Msg-id 1128585205.3738.31.camel@localhost.localdomain
Whole thread Raw
In response to Re: prefix btree implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: prefix btree implementation
Re: prefix btree implementation
List pgsql-hackers
On Wed, 2005-10-05 at 00:50 -0400, Tom Lane wrote:
> Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> > 1/ What types of prefix compression shall we support?
> 
> Given the requirement of datatype independence, this idea seems a
> complete nonstarter to me...

It would be possible to compress on similar values, since we know the
output of the comparison in the final stage of the sort of the index
build. That wouldn't need to rely upon anything to do with the datatype,
since "they are equal" is a fact outside the encapsulation, and is
arrived at by use of the datatype's own comparison logic.

But that isn't prefix compression, just compression.

But why do we want this? Its very easy to work out a data-aware
prefixing or compression scheme and then encapulate that in a function.
The function can then be used in a functional index and the usage hidden
behind a view.

It might be worth teaching the optimiser that if it has an index on an
immutable function that if we have WHERE x = k and a functional index on
f(x) then we can access the functional index with 
f(x) = f(k), as long as we also reapply the original WHERE clause. 

Best Regards, Simon Riggs




pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: current_user versus current_role SOLVED
Next
From: Dmitry Karasik
Date:
Subject: Re: prepared queries in plperl