Tom,
Actually, if you need to squeeze a few more bits into that word, the
thing to do would be to get rid of storing the tuple length there.
This would involve adding the same type of indirection header that
we use for HeapTuples, so that the length would be available at need
without going back to the item pointer. I
I feel the other one is easy. To store the hint bits inside the ItemId, in the place of size. We have 16 bits there.Whenever the size is required, we need to follow the offset and goto the corresponding tuple and then take the size from there. The change seems to be minimal, but please bear with me, if i am very ignorant about something.
Squeezing cmin in there is just fantasy though.
I think we can get away with this, by making the person, who inserts and selects in the same transaction to go and find the visibility through heap. In the Index tuple hint bits, we can note down, if the command is a simple insert/update/delete. By Simple insert, i mean that it doesn't have a select. So if that is the case, it can be made visible to statements within the same transaction. We can even document, that people can just insert a savepoint between their insert and select. This would increase the xid and make that tuple visible within the same transaction. All that seems to be possible.
Thanks,
Gokul.