Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"D. Dante Lorenso" <dante@xxxxxxxxxxx> 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux