But adding 24 bytes to every index entry seems
pretty unlikely to be a win anyways.
We actually wanted to make it optional. Not every index will be like that. More than that we can make it into 16 bytes. Only commands within the same transaction will not be able to do a index only scan.
This seems like a non-starter to me. We would lose the option of
doing sequential scans and the ability to have any other indexes on
the table. That would be comparable to Oracle circa 1985. We can do
better with stuff like Heikki's "grouped index tuple" and the
visibility map which don't interfere with other features as much.
Sequential scans can be done on IOTs, just scan through the leaf pages. I think you are talking about IOTs with overflow regions.
As i said already, this serves a different set of options to the DB Designer.
I don't think these three are actually related. Afaict neither IOT nor
visibility information in indexes depend on refinding keys in the
index. But it's possible I'm missing something. Even so they're still
three separate issues.
If we have visibility information in a heap, we need to goto the same index tuple, whenever there is a update/delete. Now if there is a broken function, it won't let us reach the index from the heap tuple . Hope you are able to get it.
Thanks,
Gokul.