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