Alternative idea is to have MVCC-aware indexes. This approach looks more attractive for me. In this approach you basically need xmin, xmax fields in index tuples. On insertion of index tuple you fill it's xmin. On update, previous index tuple is marked with xmax.
+1
xmax can be provided through to index by indexam when 1) we mark killed tuples, 2) when we do indexscan of index entry without xmax set.
xmax can be set as a hint on normal scans, or set as part of an update, as the index chooses
After that outdated index tuples might be deleted in the lazy manner when page space is required.
That is already done, so hardly any change there.
Also, we can
have special bit for "all visible" index tuples. With "all visible" bit set this tuple can get rid of visibility fields. We can do this for index tuples, because if index tuple requires extra space we can split the page, in spite of heap where tuples are fixed in pages and xmax needs to be updated in-place.
Keeping the xmin/xmax would also be useful for historical indexes, i.e. indexes that can be used to search for data with historic snapshots.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
