Re: SELECT ... FOR UPDATE performance costs? alternatives? - Mailing list pgsql-general

From Tom Lane
Subject Re: SELECT ... FOR UPDATE performance costs? alternatives?
Date
Msg-id 17644.1187242306@sss.pgh.pa.us
Whole thread Raw
In response to SELECT ... FOR UPDATE performance costs? alternatives?  ("D. Dante Lorenso" <dante@lorenso.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: User-Friendly TimeZone List
Next
From: David Fetter
Date:
Subject: Re: language interface in postgresql