Tom Lane wrote:
> No. For starters, we couldn't guarantee that insertion order is the
> same as transaction commit order. Even if we did, your assumption
> that commit order is the same as visibility is too simplistic. And
> none of this works if the index isn't unique.
Ahh, I get it, (again, correct me if I am wrong) multiple references in a
non-unique index are handled the same way as multiple versions of the same
tuple. When an index entry is found, presumably, all the tuples are loaded, all
the unique "rows" are identified and the latest "visible" version of each of
them are returned.
I wonder, is there some way inexpensive ordering up front on updates can help
increase select performance? A very good problem indeed.
