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
> 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

Peter Geoghegan

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to