Re: SELECT ... FOR UPDATE performance costs? alternatives?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SELECT ... FOR UPDATE performance costs? alternatives?
Дата
Msg-id 17644.1187242306@sss.pgh.pa.us
обсуждение исходный текст
Ответ на SELECT ... FOR UPDATE performance costs? alternatives?  ("D. Dante Lorenso" <dante@lorenso.com>)
Список pgsql-general
"D. Dante Lorenso" <dante@lorenso.com> writes:
> ... When my server is under severe load, however, this function begins to
> take a long time to execute and I begin to suspect that the FOR UPDATE
> lock might be locking the whole table and not just the row.

FOR UPDATE only locks the selected row(s).  However, the way you've got
this coded, every incoming server will try to select the same row, which
means that whichever one gets there first will block all the others
until it commits (and releases its row lock).  Are you careful to commit
immediately after making this update?

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: User-Friendly TimeZone List
Следующее
От: David Fetter
Дата:
Сообщение: Re: language interface in postgresql