Re: SELECT ... FOR UPDATE performance costs? alternatives?

Поиск
Список
Период
Сортировка
От Douglas McNaught
Тема Re: SELECT ... FOR UPDATE performance costs? alternatives?
Дата
Msg-id 87wsvvtvbg.fsf@suzuka.mcnaught.org
обсуждение исходный текст
Ответ на Re: SELECT ... FOR UPDATE performance costs? alternatives?  ("D. Dante Lorenso" <dante@lorenso.com>)
Ответы Re: SELECT ... FOR UPDATE performance costs? alternatives?
Список pgsql-general
"D. Dante Lorenso" <dante@lorenso.com> writes:

> I need logic like "atomic test and set" or pop 1 item off the queue
> atomically and tell me what that item was.
>
> In my situation, there are a dozen or so machines polling this queue
> periodically looking for work to do.  As more polling is occurring,
> the locks seem to be taking longer so I was worried table-level locks
> might be occurring.

How quickly after you update the row status are you comitting (and
releasing locks)?  I have apps that basically do:

SELECT id FROM job_table WHERE status = 'New' FOR UPDATE;
UPDATE job_table SET status = 'Processing' WHERE id IN (<set of IDs>);
COMMIT; -- releases all locks

<process each job in the list we got and update its status>

This has worked very well for me.

-Doug

В списке pgsql-general по дате отправления:

Предыдущее
От: Decibel!
Дата:
Сообщение: Re: Performance question
Следующее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: how to get id of currently executed query?