увы, решение, конечно, не блещет, тут вы — правы! да, вы правы — выигрышь в производительности тут исключительно в том, что обновение занимает меньше времени чем обработка :)
однако а) с своей задачей справляется великолепно б) было введено в действие менее чем за сутки (это включая тесты на производительность!)
Часть ERP системы: конструктор «событий», то бишь администратор портала может сам собирать сложные логические «блоки», которые прорадабываются в случае разные событий. Банальный пример — пользователь системы создаёт в CRM модуле новый контакт с набором характеристик. Админ в «конструкторе событий» описывает логику, где проверяются харакретистики и выполняются разные действия, например: спросить подтверждения у менеджера группы, отправить мейл тому-то, присобачить контакт к такой-то компании, создать где-то какую-то линию действий для этого контакта и тд и тп. В итоге получаются довольно сложные схемы. Если учесть что «событий» в даже очень простой ERP системе может генерироваться сотни в минуту, задача по отработке логики оных нетривиальна. Но как показывает практика — нет невозможных задачь ;)
однако а) с своей задачей справляется великолепно б) было введено в действие менее чем за сутки (это включая тесты на производительность!)
select id from queue where locked = 'false' and execute_at < NOW() LIMIT 1 FOR UPDATE
select id from queue where locked = 'false' and execute_at FOR UPDATE