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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
