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 (which includes both column triggers and a WHEN clause for triggers) вам придётся прибегнуть ко второму решению.

Answer 3

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

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