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

Поиск
Список
Период
Сортировка
От Kevin Burke
Тема Re: UPDATE grabs multiple rows when it seems like it should only grab one
Дата
Msg-id CAEYV4pY+Aoa2mFEyRhx26i0fszKKjqe0+K06JYSc5UZuTyJbyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UPDATE grabs multiple rows when it seems like it should only grab one  (Kevin Burke <burke@shyp.com>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Burke
Дата:
Сообщение: Re: UPDATE grabs multiple rows when it seems like it should only grab one
Следующее
От: Yaroslav
Дата:
Сообщение: Re: BUG #14107: Major query planner bug regarding subqueries and indices