On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: >> I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for >> speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as "like >> CHECK_UNIQUE_PARTIAL, but you don't have to insert the index tuple if >> there's a conflict". I think it'd be better to define it as "like >> CHECK_UNIQUE_YES, but return FALSE instead of throwing an error on >> conflict". The difference is that the aminsert would not be allowed to >> return FALSE when there is no conflict. > > Suppose we do it that way. Then what's the difference between > CHECK_UNIQUE_SPECULATIVE and CHECK_UNIQUE_PARTIAL? You've just > effectively required the CHECK_UNIQUE_YES case to not physically > insert a physical tuple before throwing an error, which does not seem > essential to the existing definition of CHECK_UNIQUE_YES -- you've > redefined CHECK_UNIQUE_YES in a way that nbtree happens to meet at the > moment. If we had an amcanunique AM that worked a bit like exclusion > constraints, this new obligation for CHECK_UNIQUE_YES might make it > impossible for that to work.
Another more obvious and important thing: CHECK_UNIQUE_YES waits for conflicts to be resolved before returning to its caller. If you don't get an error, you're done. CHECK_UNIQUE_PARTIAL never waits, and if we add a CHECK_UNIQUE_SPECULATIVE, it ought to not wait either. Sure, if a speculative inserter detects a conflict, it still has to wait. But not in the aminsert call, and not until it cleans up its physical insertion (by super-deleting). Clearly a CHECK_UNIQUE_SPECULATIVE would have to be much closer to CHECK_UNIQUE_PARTIAL than to CHECK_UNIQUE_YES. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
