On 2014-10-01 12:44:25 +0300, Heikki Linnakangas wrote:
> I didn't realize that "promise index tuples" were even seriously discussed.
> I guess that can be made to work, too, although I don't see the point. It
> wouldn't work with GiST indexes, for the same reasons as page-level locking
> won't work (a tuple can legally be inserted anywhere in a GiST index - it
> just degrades the index making searching more expensive). And lossy GiST
> opclasses are a problem too.
> It's actually more similar to approach #1 in that it puts the responsibility
> of the locking in the indexam. You would probably need the same kind of API
> changes to the indexam, and you could well imagine one indexam to implement
> index promise tuples, while another one might use heavy-weight locks. I
> don't see the advantage of #3.
I don't think all of that is of necessary consequence. What I was
thinking of would actually works similar to #2: Just that, instead of a
heap tuple, it inserts a index tuple that a) has a PROMISE_TUPLE flag
set and b) the itemid points towards a xid instead of a heap
tuple. That's sufficient for detecting uniqueness violations using
a similar approach like in your proposal. Which does *not* have to
happen inside the AM.
Yes, it'd require some indexam API changes, but I don't think they'd be
to severe. Most importantly the ability to insert, return promise tuples to
outside and API to repoint a promise tuple to a real entry.
I haven't thought about lossy indexes, but I actually do think they
could be made work with that strategy.
The difference to #2 primarily is that it avoids speculatively inserting
in both the heap and index and just inserts into the index, thereby
detecting conflicts a bit earlier, after less work.
But, as I said, I'm ok with pursuing #2 on the basis that it's quite
likely to be simpler
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services