> >> ... The really serious problem I've got with it is that
> >> it'd foreclose the possibility of returning actual index keys from
btree
> >> indexes, thus basically killing the usefulness of that idea. I'm
not
> >> convinced it would offer enough gain to be worth paying that price.
>
> > I do not see the serious problem ? The one key that is stored would
> > represent all tuples it points to.
>
> No, the entry represents a range of values for which the one key is
the
> lower bound. You don't know just what the keys are for the other
> tuples, unless you go to the heap and look.
Thanks for explaining. I think that idea stands in the way of future
improvements and should be dropped, yes.
> We could restrict GIT to only represent tuples with exactly the same
> key, but that takes away a whole lot of its use-case (especially so
> now that HOT is in there).
Ok, I was forgetting pg's outstanding "partial index" feature.
In pg you will most likely exclude highly duplicate keys from the index.
Since other dbs don't have this feature, it is common to have highly
duplicate keys (millions) there (unless you use very ugly workarounds).
I agree that the possibility of returning actual index keys and
filtering
rows early has more merrit. It could also be used to skip forward, when
the
qual misses middle key columns.
I do still see compressing exactly equal keys (or exactly equal parts),
but not restricted to the same heap page, as a useful btree TODO
(especially for long non unique keys).
But it may really not be so important in pg.
Andreas