Doug McNaught <[EMAIL PROTECTED]> writes:
Short answer: MVCC tuple visibility status isn't (and can't be) stored
in the index.
Well the "can't" part is false or at least unproven. From prior discussion the only thing that would be technically challenging would be avoiding deadlocks.
Rather than yank the MVCC visibility around, how about a (relatively small) change to the query plan ...
I take it that it is a very reasonable assumption that only a small proportion of index records are actually invalid (else Yurk why use the index?). In that case, how about tacking the heap table row ptr onto result tuples, and letting them percolate up through the tree?
Since you're using an index at all, the planner must be expecting a restricted set of rows to make it up through to the root. If there is any filter criteria against the values from the index rows, you won't even have to check rows for tuple visibility, that don't pass that filter.
As soon as you rise to a point where (index) rows will either be multiplied (a join) or combined (a group-by/distinct), you can validate them against the heap file in relatively large batches, with a hash caching of which ones have been checked for visibility.
Just a thought.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
