Re: Refactoring speculative insertion with unique indexes a little

On 07/01/2015 09:19 PM, Peter Geoghegan wrote:
> 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.

Why is it not OK for aminsert to do the waiting, with 
CHECK_UNIQUE_SPECULATIVE?

- Heikki