Re: UPDATE grabs multiple rows when it seems like it should only grab one

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