If i have got over excited in the previous update, please ignore that.

a) We are already going from table to index to do unique checks. This is the
same thing, which we will do to go and update the snapshot in the indexes.
b) The way, it should work would be to have a check on whether the operator
is broken / function is volatile and put the onus on the user to make sure
that they are updated correctly.
c) In the ItemId, instead of removing the size field completely, we can
store the size as size/4(since it is MaxAligned). This will save us 2 bits.
In index we only need 13 bits to store the complete size in the tuple, but
we use 15 bits in the iid, so again we can have two more bit savings there.
That's sufficient for us to express the hint fields in a index. I think
Karl's way of expressing it requires only one bit, which looks very
efficient. So we can check the hint bits from the iid itself.

So just with a addition of 8 bytes per tuple, we can have the snapshot
stored with the index. Can someone please comment on this?

Thanks,
Gokul.

In response to

• Re: A thought on Index Organized Tables at 2010-02-27 05:42:41 from Gokulakannan Somasundaram

Responses

• Re: A thought on Index Organized Tables at 2010-02-28 14:02:54 from Greg Stark
• Re: A thought on Index Organized Tables at 2010-02-28 15:47:54 from Tom Lane

pgsql-hackers by date

Next:	From: Mark Kirkwood	Date: 2010-02-28 06:06:36
	Subject: Re: Lock Wait Statistics (next commitfest)
Previous:	From: Greg Stark	Date: 2010-02-28 06:01:49
	Subject: Re: Hot Standby query cancellation and Streaming Replication integration