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

Where can I read more about the effects of that? I see this:

When using LIMIT, it is important to use an ORDER BY clause that constrains
the result rows into a unique order. Otherwise you will get an
unpredictable subset of the query's rows. You might be asking for the tenth
through twentieth rows, but tenth through twentieth in what ordering? The
ordering is unknown, unless you specified ORDER BY.

Is there anything else I can read?

On Fri, Apr 22, 2016 at 8:04 PM, Kevin Burke <burke(at)shyp(dot)com> wrote:

> 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(at)sss(dot)pgh(dot)pa(dot)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
>

--
kevin