Следующий важный момент — Bloat в PostgreSQL. К сожалению, здесь нет волшебного решения: помогает только агрессивный VACUUM и ANALYZE
detach партиций или truncate с копирование живых данных во временную табличку помогут даже в случае долгих транзкций, так как это не MVCC safe операции
плюсую к вопросу, понятно если надо было бы обеспечить транзакционость основной логики и запуск задачи, но раз для задач отдельная база, то может что-то из nosql лучше подошло бы
или в целом написать свой transactional outbox с аккуратным truncate таблиц или ротацией партиций против bloat при долгих транзакциях не должно быть сильно сложнее. Выше уже скидывал, как пример https://github.com/Toloka/pg-queue-playground
пример transactional outbox (это не задачи с приоритетами) https://github.com/Toloka/pg-queue-playground. Но есть примеры оптимизаций для обработчиков where id > last_processed и выключение ожидания синхронной реплики. А также ручной vacuum через truncate таблиц, чтобы долгие транзакции не мешали удалить bloat
# "Не баг, а фича": добавлять через API задания в пул можно только тогда,
# когда сам пул создан через API
На сколько я знаю, разницы быть не должно. kucev можете подсказать, как проявляется невозможность добавить задания в пул через API, если он создан через интерфейс?
detach партиций или truncate с копирование живых данных во временную табличку помогут даже в случае долгих транзкций, так как это не MVCC safe операции
А можете рассказать как обеспечиваете атомарность между изменениями в основной базе и запуском соответсвующих задач в другой?
плюсую к вопросу, понятно если надо было бы обеспечить транзакционость основной логики и запуск задачи, но раз для задач отдельная база, то может что-то из nosql лучше подошло бы
или в целом написать свой transactional outbox с аккуратным truncate таблиц или ротацией партиций против bloat при долгих транзакциях не должно быть сильно сложнее. Выше уже скидывал, как пример https://github.com/Toloka/pg-queue-playground
пример transactional outbox (это не задачи с приоритетами) https://github.com/Toloka/pg-queue-playground. Но есть примеры оптимизаций для обработчиков where id > last_processed и выключение ожидания синхронной реплики. А также ручной vacuum через truncate таблиц, чтобы долгие транзакции не мешали удалить bloat
Outbox producer и есть очередь в базе для перекладывания во внешнюю
Спасибо за статью. Но хочется ещё пример с добавление реплики
# "Не баг, а фича": добавлять через API задания в пул можно только тогда,
# когда сам пул создан через API
На сколько я знаю, разницы быть не должно. kucev можете подсказать, как проявляется невозможность добавить задания в пул через API, если он создан через интерфейс?