Re: Refactoring speculative insertion with unique indexes a little - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Refactoring speculative insertion with unique indexes a little
Date
Msg-id CAM3SWZS=Zz_94sTVm=k=axkJonwvde4QF7OLZctfworXM5EoHg@mail.gmail.com
Whole thread Raw
In response to Re: Refactoring speculative insertion with unique indexes a little  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Refactoring speculative insertion with unique indexes a little
List pgsql-hackers
On Wed, Dec 16, 2015 at 11:20 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> (A couple of months later)
> This is not an actual fix, but an optimization, no?
> UNIQUE_CHECK_SPECULATIVE is just used to optimize a couple of code
> paths in the case of a insert conflicting during btree insertion..
>
> In any case, at this point 9.5 is really aimed to be stabilized, so
> targeting only master is a far saner approach IMO for this patch.
> Pushing that in 9.5 a couple of months back may have given enough
> reason to do so... But well life is life.

No, this really isn't an optimization at all. It has nothing to do
with performance, since I think that unnecessarily inserting an index
tuple in practice has very little or no appreciable overhead.

The point of avoiding that is that it makes no sense, while doing it
implies that it does make sense. (i.e. It does not make sense to
insert into a B-Tree leaf page an IndexTuple pointing to a speculative
heap tuple with the certain knowledge that we'll have to super-delete
the speculative heap tuple in the end anyway).

This is 100% about clarifying the intent and design of the code.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: andres@anarazel.de (Andres Freund)
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Gaetano Mendola
Date:
Subject: pg_tables bug?