Escalar TRIGGER (s) de PostgreSQL

¿Cómo Postgres dispara las escalas del mecanismo?

Tenemos una gran instalación de PostgreSQL e intentamos implementar un sistema basado en eventos utilizando tablas de registro y TRIGGER (s).

Básicamente nos gustaría crear un GATILLO para cada tabla que queremos que se nos notifique para una operación ACTUALIZAR / INSERTAR / BORRAR. Una vez que se active este disparador, ejecutará una función que simplemente agregará una nueva fila (codificando el evento) a una tabla de registro que luego sondearemos desde un servicio externo.

Antes de comenzar con TRIGGER (s) de Postgres, nos gustaría saber cómo se escalan: ¿cuántos disparadores podemos crear en una sola instalación de Postgres? ¿Afectan el rendimiento de la consulta? ¿Alguien ha intentado esto antes?

Básicamente nos gustaría crear un GATILLO para cada tabla que queremos que se nos notifique para una operación ACTUALIZAR / INSERTAR / BORRAR. Una vez que se active este disparador, ejecutará una función que simplemente agregará una nueva fila (codificando el evento) a una tabla de registro que luego sondearemos desde un servicio externo.

Ese es un uso bastante estándar para un disparador.

Antes de comenzar con TRIGGER (s) de Postgres, nos gustaría saber cómo se escalan: ¿cuántos disparadores podemos crear en una sola instalación de Postgres?

Si sigue creándolos, eventualmente se quedará sin espacio en disco.

No hay un límite específico para los desencadenantes.

Los límites de PostgreSQL están documentados en la página acerca de .

¿Afectan el rendimiento de la consulta?

Depende del tipo de disparador, el idioma del disparador y lo que hace el disparador.

Un simple BEFORE ... FOR EACH STATEMENTdisparador PL / PgSQL que no hace nada tiene una sobrecarga cercana a cero.

FOR EACH ROWlos disparadores tienen una sobrecarga mayor que los FOR EACH STATEMENTdisparadores. Escalado, obviamente, con los recuentos de filas afectados.

AFTERlos desencadenantes son más caros que los BEFOREdesencadenantes porque deben ponerse en cola hasta que la instrucción termine de hacer su trabajo y luego ejecutarse. No se derraman en el disco si la cola se hace grande (al menos en 9.4 y posteriores, puede cambiar en el futuro), por lo que las AFTERcolas de activación enormes pueden hacer que la memoria disponible se desborde, lo que resulta en la anulación de la instrucción.

Un activador que modifica la NEWfila antes de insertar / actualizar es más barato que un activador que hace DML.

El caso de uso específico que desee funcionaría mejor con una mejora en progreso que podría convertirse en PostgreSQL 9.5 (si tenemos suerte), donde los FOR EACH STATEMENTdesencadenantes pueden ver tablas OLDy virtuales NEW. Esto no es posible en las versiones actuales de PostgreSQL, por lo que debe usar FOR EACH ROWdesencadenantes.

¿Alguien ha intentado esto antes?

Por supuesto. Es un uso bastante estándar para los desencadenantes, junto con auditorías, comprobación de cordura, etc.

Deberá buscar LISTENy encontrar NOTIFYuna buena manera de despertar a su trabajador cuando ocurran cambios en la tabla de tareas.

Ya estás haciendo lo más importante al evitar hablar con sistemas externos directamente desde los disparadores. Eso tiende a ser problemático para el rendimiento y la fiabilidad. Las personas a menudo intentan hacer cosas como enviar correo directamente desde un disparador, y esas son malas noticias.

Es una respuesta un poco tardía, pero podría ser útil para futuros lectores.

Hoy en día (en las versiones 10,11,12) no necesitamos almacenar los mismos datos dos veces (en WAL by PG y manualmente). Podemos usar la mecánica de decodificación lógica de Postgre (igual que la replicación lógica) para rastrear todos o algunos cambios en nuestros datos (o enviar esos eventos a alguna cola como kafka para analizarlos más adelante)