Re: Block B-Tree concept

Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Imagine a normal B-tree just like what we have now. But when there is 
> more than one tuple on the same heap page with consecutive index keys, 
> we represent all of them in a single index tuple that contains the key 
> of the first one of them, and a (run-length encoded) bitmap of the 
> OffsetNumbers.

At first I thought that was a typo, and instead of "consecutive" you
meant to write "equal".  I gather from the later statement

> I'm not very interested in the case where you have a lot of equal keys, 
> I think the bitmap index am is more suitable for that.

that indeed you meant to write "consecutive", and I've got a problem
with that: define "consecutive".  In a datatype independent fashion,
please.  I also wonder how you are going to implement splitting and
merging of runs, which will certainly be necessary if this isn't to be
a constantly-requires-REINDEX thing.
        regards, tom lane