Re: Block B-Tree concept

Heikki Linnakangas <heikki(at)enterprisedb(dot)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