Background task, большая таблица, CURSOR и update, стоит ли открывать 2 сессии?

Здравствуйте.

Есть CLI утилита на php которая обходит всю таблицу (потенциально не ограниченного размера) и, при определенных условиях, делает update некоторых строк. Обход происходит неспешно, скорость значения не имеет, частота обхода "тогда когда это нужно админу".

Решил делать такой проход через курсоры. Поскольку курсор работает в рамках транзакции (WITHOUT HOLD) то и все update до конца обхода таблицы скапливаются в этой транзакции и применяются только после коммита.

Тут я вижу два варианта:

1) Пусть update'ы копятся в транзакции. Но рассчитаны ли транзакции постгреса на большой объём данных? Предположительно update'ов могут быть тысячи, а в последующем, при некоторых условиях, десятки тысяч.

2) Запускать 2 сессии, через одну создавать курсор, а через вторую делать update'ы (т.к. необходимость видимости update'а в рамках транзакции курсора отсутствует)

Собственно вопрос: стоит ли волноваться за размер буфера транзакции в данной ситуации и открывать 2 сессии к базе или я зря парюсь на пустом месте?
  • Вопрос задан
  • 183 просмотра
Пригласить эксперта
Ответы на вопрос 1
leahch
@leahch
3D специалист. Dолго, Dорого, Dерьмово.
Вообще-то зря паритесь. Но, есть небольшие но. Не помню как в постгресе, но по аналогии с версионными базами данных (а постгрес как раз оно, по типу оракла), то записи в рамках транзакции копируются с новой версией, а по завершении транзакции просто остаются на месте. Вот откат транзакции, особенно большой, может быть очень болезненным.
В общем, упереться можно только в два момента, нехватка памяти, и нехватка диска. Когда до этого дойдет, то можно выбирать записи кусочками по 1000 и более штук. Их обрабатывать и коммитить, Далее выбирать следующий кусочек. Так будет легче и для базы и для отслеживания.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы