Re: Refactoring speculative insertion with unique indexes a little

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Refactoring speculative insertion with unique indexes a little
Дата
Msg-id CAM3SWZS=Zz_94sTVm=k=axkJonwvde4QF7OLZctfworXM5EoHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Refactoring speculative insertion with unique indexes a little  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Refactoring speculative insertion with unique indexes a little  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: andres@anarazel.de (Andres Freund)
Дата:
Сообщение: Re: Freeze avoidance of very large table.
Следующее
От: Gaetano Mendola
Дата:
Сообщение: pg_tables bug?