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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: SELECT ... FOR UPDATE performance costs? alternatives?
Date: 2007-08-16 05:31:46
Message-ID: 17644.1187242306@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"D. Dante Lorenso" <dante(at)lorenso(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Fetter 2007-08-16 05:43:01 Re: language interface in postgresql
Previous Message Tom Lane 2007-08-16 05:28:11 Re: User-Friendly TimeZone List