> * GIT (Grouped Index Tuple) indexes, which achieve index space savings
> in btrees by having a single index tuple represent multiple heap
tuples
> (on a single heap page) containing a range of key values. I am not
sure
> what the development status is --- Heikki had submitted a completed
> patch but there seemed to be agreement on making changes, and that's
not
> been done AFAIK. 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.
> Another issue is that we'd need to check how much of the use-case for
> GIT has been taken over by HOT.
I do not see the serious problem ? The one key that is stored would
represent all tuples it points to. So the interface could eighter
be designed to allow skipping the key in one go, or return the same
key repeatedly. All that the second approach would need is return
the key and the heap tuple pointer in two different vars.
Andreas
