Postgres: сужение области действия триггера

Question

(Postgres 8.3)

Я работаю с таблицей БД X шириной более 100 столбцов (что, к сожалению, не могу изменить), многие из которых обновляются постоянно и очень часто в соответствии с обычным бизнес-процессом.

У меня есть требование обновить таблицу Y на основе обновлений определенного столбца foo в X , обновленных в результате необычного бизнес-процесса. Однако из-за очень большого количества обновлений против X простое применение триггера, который проверяет X.foo , чтобы решить, обновлять ли Y , считается неприемлемым.

Таблица Y тоже не конец линии, есть цепочка предков, несколько глубоких, и все они должны пузыриться до корня.

Единственные решения, о которых я могу думать:

• разбиение X на несколько таблиц (не разрешено)
• явно вносит обновления в Y (и Z и другие) как часть бизнес-логики для обновления X , но это будет иметь большое значение занимают много места и оставляют много места для того, чтобы кто-то ошибся или пропустил это, когда им нужно реализовать то же самое в другом процессе. И это явно не очень хороший дизайн (который я пытаюсь постепенно исправить, где могу).

Кто-нибудь знает способ ограничения выполнения триггера по столбцу или любой другой альтернативе? Триггеры на просмотры? Другое вуду?

Answer 1

Возможно, вы сможете что-то сделать с правилами, но, как уже было сказано, триггеры, вероятно, должны быть "достаточно хорошими". Но если вы пытаетесь решить проблему управления, а не техническую проблему, правила могут вам помочь. Они будут применяться гораздо раньше во время исполнения. Остерегайтесь некоторых ловушек с ними, как правило, с последовательностями и тому подобное.

Answer 2

К сожалению, пока не будет выпущена версия 9.0 (, которая включает в себя как триггеры столбцов, так и предложение WHEN для триггеров ), вам придется прибегнуть ко второму решению.

Answer 3

Почему стандартный триггер недопустим? Запуск функции, которая сначала проверяет, является ли NEW.column_name=OLD.column_name, и просто возвращает значение, если оно одинаковое, обходится дешево. Вы можете уволить сотни тысяч из них в секунду. Ваша система, вероятно, не может обрабатывать более нескольких сотен транзакций в секунду & mdash; На 3 порядка меньше.

Условно после, отложенные триггеры в 9.0 будут быстрее, но только примерно в 2 раза быстрее, чем обычный триггер. См. соответствующий пост в блоге Depesz . Вы можете запустить некоторые тесты в Postgres 9 для разработчиков .