> * 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
