Re: can we add SKIP LOCKED to UPDATE?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 德哥 <digoal(at)126(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: can we add SKIP LOCKED to UPDATE?
Date: 2015-11-09 17:38:45
Message-ID: CAMkU=1xXqhDn_kpU1TEHt03oEK=-VdX7u5F7j2E-ekySdvz25Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 9, 2015 at 9:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?GBK?B?tcK45w==?= <digoal(at)126(dot)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.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2015-11-09 17:47:25 pg_receivexlog: spurious error message connecting to 9.3
Previous Message Pavel Stehule 2015-11-09 17:31:18 Re: proposal: PL/Pythonu - function ereport