My case is concurrency update one row(for exp 1000 client update the same row 
at the same time), and target is prevent waiting for waiters(quick return to 
use advisory lock is a method, for quick return. but not good , must use 
function(to reduce consume between client-db network).
if update can skip locked in this case, performance can improve so much.

case exp (all session update the same row):
session a:
update tbl set x=x-1 where id=1 and x>0;
session b:
update tbl set x=x-1 where id=1 and x>0;
session x:
update tbl set x=x-1 where id=1 and x>0;

best regards,

At 2015-11-10 01:38:45, "Jeff Janes" <jeff.ja...@gmail.com> wrote:
>On Mon, Nov 9, 2015 at 9:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> =?GBK?B?tcK45w==?= <dig...@126.com> writes:
>>>    PostgreSQL 9.5 added skip locked to select for update to improve 
>>> concurrency performance, but why not add it to update sql?
>> Seems like you'd have unpredictable results from the update then.
>But with use of RETURNING, you could at least know what those results
>were and so could deal with the unpredictability.
>I don't understand Digoal's use case (Google Translate does a poor job
>on the linked page), but this would be handy in conjunction with LIMIT
>(which also doesn't exist for UPDATE right now).
>update work_queue set assigned='Jeff' where assigned is null and
>skills_needed <@ '{whining,"breaking things"}'  limit 1 skip locked
>returning id, description
>In 9.5 you will be able to do it with a subselect, but putting them
>directly on the UPDATE would be easier to understand, and perhaps more
>efficient to execute.


Reply via email to