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 CAEYV4pY+Aoa2mFEyRhx26i0fszKKjqe0+K06JYSc5UZuTyJbyA@mail.gmail.com
Whole thread Raw
In response to Re: UPDATE grabs multiple rows when it seems like it should only grab one  (Kevin Burke <burke@shyp.com>)
List pgsql-bugs
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@shyp.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@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
>



--
kevin

pgsql-bugs by date:

Previous
From: Kevin Burke
Date:
Subject: Re: UPDATE grabs multiple rows when it seems like it should only grab one
Next
From: Yaroslav
Date:
Subject: Re: BUG #14107: Major query planner bug regarding subqueries and indices