Re: Refactoring speculative insertion with unique indexes a little

On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas <hlinnaka@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