Масштабирование PostgreSQL TRIGGER (s)

Как Postgres запускает механизм масштаба?

У нас есть большая установка PostgreSQL, и мы пытаемся внедрить систему на основе событий, используя таблицы журналов и TRIGGER (s).

В принципе, мы хотели бы создать TRIGGER для каждой таблицы, которую хотим получить извещения для операции UPDATE /INSERT /DELETE. Как только этот триггер срабатывает, он выполнит функцию, которая просто добавит новую строку (кодировку события) в таблицу журналов, которую мы затем опросим из внешней службы.

Прежде чем переходить к Postgres TRIGGER (s), мы хотели бы знать, как они масштабируются: сколько триггеров можно создать на одной установке Postgres? Оказывает ли они влияние на производительность запросов? Кто-нибудь раньше попробовал это?

12 голосов | спросил Ugo Matrangolo 7 Jpm1000000pmWed, 07 Jan 2015 19:50:03 +030015 2015, 19:50:03

1 ответ


13
  

В принципе, мы хотели бы создать TRIGGER для каждой таблицы, которую хотим получить извещения для операции UPDATE /INSERT /DELETE. Как только этот триггер срабатывает, он выполнит функцию, которая просто добавит новую строку (кодировку события) в таблицу журналов, которую мы затем опросим из внешней службы.

Это довольно стандартное использование для триггера.

  

Прежде чем переходить к Postgres TRIGGER (s), мы хотели бы знать, как они масштабируются: сколько триггеров можно создать на одной установке Postgres?

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

Нет ограничений для триггеров.

Пределы PostgreSQL документированы на странице about .

  

Оказывают ли они влияние на производительность запросов?

Это зависит от типа триггера, языка триггера и того, что делает триггер.

Простой PL /PgSQL BEFORE ... FOR EACH STATEMENT триггер, который ничего не делает, имеет почти нулевые служебные данные.

FOR EACH ROW имеют более высокие накладные расходы, чем FOR EACH STATEMENT

AFTER триггеры стоят дороже, чем BEFORE, потому что они должны быть поставлены в очередь, пока оператор не закончит выполнение своей работы, а затем выполнит. Они не разливаются на диск, если очередь становится большой (по крайней мере, в 9.4 и ниже, может измениться в будущем), поэтому огромный AFTER триггер очереди могут привести к переполнению доступной памяти, в результате чего оператор прерывается.

Триггер, который изменяет строку NEW до того, как вставка /обновление будет дешевле, чем триггер, который выполняет DML.

Конкретный вариант использования, который вы хотите, будет лучше работать с улучшением в ходе выполнения, которое могло бы превратиться в PostgreSQL 9.5 (если нам повезет), где FOR EACH STATEMENT могут видеть виртуальные OLD и NEW. Это невозможно в текущих версиях PostgreSQL, поэтому вы должны использовать триггеры FOR EACH ROW.

  

Пробовал ли кто-нибудь раньше?

Конечно. Это довольно стандартное использование триггеров, а также аудит, проверка работоспособности и т. Д.

Вам нужно посмотреть LISTEN и NOTIFY - это хороший способ разбудить вашего работника, когда происходят изменения в таблице задач.

Вы уже делаете самое главное, избегая общения с внешними системами непосредственно из триггеров. Это имеет тенденцию быть проблематичным для производительности и надежности. Люди часто пытаются делать такие вещи, как отправлять почту прямо из триггера, и это плохая новость.

ответил Craig Ringer 8 Jam1000000amThu, 08 Jan 2015 05:54:18 +030015 2015, 05:54:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132