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 CAEYV4pa-P8_VPExg1w3cSmReK4V4KMfkHMqDQHMAmDgiqyPNpQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UPDATE grabs multiple rows when it seems like it should only grab one  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: UPDATE grabs multiple rows when it seems like it should only grab one
Список 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 по дате отправления: