Re: UPDATE grabs multiple rows when it seems like it should only grab one - Mailing list pgsql-bugs

From Kevin Burke
Subject Re: UPDATE grabs multiple rows when it seems like it should only grab one
Date
Msg-id CAEYV4pa-P8_VPExg1w3cSmReK4V4KMfkHMqDQHMAmDgiqyPNpQ@mail.gmail.com
Whole thread Raw
In response to Re: UPDATE grabs multiple rows when it seems like it should only grab one  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UPDATE grabs multiple rows when it seems like it should only grab one
List pgsql-bugs
Thanks both of you for your help; I can see why the first query was
incorrect.

On Fri, Apr 22, 2016 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> LIMIT without an ORDER BY is ill-defined.


I moved to a CTE, but isn't LIMIT without an ORDER BY OK for this use case?
A series of dequeuers are more or less trying to find any queued job; it
doesn't really matter which one they get. I may be getting the indexes
wrong, but as far as I can tell it's about twice as expensive to fetch a
row with an ORDER BY as without it.

(There's probably a better design here, where I do batch fetches and then
distribute the work; let's ignore that for the moment).

--
kevin

pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: UPDATE grabs multiple rows when it seems like it should only grab one
Next
From: Kevin Burke
Date:
Subject: Re: UPDATE grabs multiple rows when it seems like it should only grab one