Re: Insert performance

Поиск
Список
Период
Сортировка
Искать
От
Carlos Moreno
Тема
Re: Insert performance
Дата
Msg-id
45EDAAE4.7000500@mochima.com
Ответ на
Список
Дерево обсуждения
Insert performance "hatman" <joel.winteregg@gmail.com>
Re: Insert performance Richard Huxton <dev@archonet.com>
Re: Insert performance joël Winteregg <joel.winteregg@gmail.com>
Re: Insert performance Richard Huxton <dev@archonet.com>
Re: Insert performance joël Winteregg <joel.winteregg@gmail.com>
Re: Insert performance Richard Huxton <dev@archonet.com>
Re: Insert performance "hatman" <joel.winteregg@gmail.com>
Re: Insert performance Andreas Kostyrka <andreas@kostyrka.org>
Re: Insert performance "hatman" <joel.winteregg@gmail.com>
Re: Insert performance Richard Huxton <dev@archonet.com>
Re: Insert performance Andreas Kostyrka <andreas@kostyrka.org>
Re: Insert performance Carlos Moreno <moreno_pg@mochima.com>
Re: Insert performance Csaba Nagy <nagy@ecircle-ag.com>
Re: Insert performance Carlos Moreno <moreno_pg@mochima.com>
Csaba Nagy wrote:

>I only know to answer your no. 2:
>  
>
>>2) What about the issue with excessive locking for foreign keys when
>>inside a transaction?  Has that issue disappeared in 8.2?  And if not,
>>would it affect similarly in the case of multiple-row inserts?
>>    
>>
>
>The exclusive lock is gone already starting with 8.0 IIRC, a
>non-exclusive lock on the parent row is used instead. Thing is that this
>is still too strong ;-)
>
>The proper lock would be one which only prevents modification of the
>parent key, other updates would be safe on the same row.
>
>In any case, the current behavior is much better than what was before.
>  
>

*Much* better, I would say --- though you're still correct in that it is 
still
not the right thing to do.

In particular, with the previous approach. there was a serious performance
hit when concurrent transactions reference the same keys --- that is, after
having taken measures to avoid deadlocks, some transactions would have
to *wait* (for no good reason) until the other transaction is completed and
the exclusive-access lock is released.  For high-traffic databases this 
can be
a quite severe performance hit.  I'm glad it has been fixed, even if only
partially.

Thanks,

Carlos
--

В списке pgsql-performance по дате отправления
От: Neelam Goyal
Дата:
От: Alex Deucher
Дата:
FAQ