Heikki Linnakangas <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
