Fondamentalmente vorremmo creare un TRIGGER per ogni tabella che vogliamo ricevere una notifica per un'operazione UPDATE / INSERT / DELETE. Una volta attivato, questo trigger eseguirà una funzione che aggiungerà semplicemente una nuova riga (codifica dell'evento) a una tabella di registro che eseguiremo quindi il polling da un servizio esterno.
Questo è un uso piuttosto standard per un trigger.
Prima di andare all in con Postgres TRIGGER vorremmo sapere come si ridimensionano: quanti trigger possiamo creare su una singola installazione di Postgres?
Se continui a crearli, alla fine rimarrai senza spazio su disco.
Non esiste un limite specifico per i trigger.
I limiti di PostgreSQL sono documentati nella pagina delle informazioni .
Interessano le prestazioni delle query?
Dipende dal tipo di trigger, dalla sua lingua e da cosa fa il trigger.
Un semplice BEFORE ... FOR EACH STATEMENTtrigger PL / PgSQL che non fa nulla ha un sovraccarico quasi zero.
FOR EACH ROWi trigger hanno un overhead più elevato rispetto ai FOR EACH STATEMENTtrigger. Il ridimensionamento, ovviamente, con i conteggi delle righe interessate.
AFTERi trigger sono più costosi dei BEFOREtrigger perché devono essere messi in coda fino a quando l'istruzione termina di fare il suo lavoro, quindi vengono eseguiti. Non vengono riversati sul disco se la coda diventa grande (almeno in 9.4 e sotto, potrebbe cambiare in futuro), quindi enormi AFTERcode di trigger possono causare il sovraccarico della memoria disponibile, con conseguente interruzione dell'istruzione.
Un trigger che modifica la NEWriga prima di inserire / aggiornare è più economico di un trigger che esegue DML.
Il caso d'uso specifico che desideri avrebbe prestazioni migliori con un miglioramento in corso che potrebbe trasformarsi in PostgreSQL 9.5 (se siamo fortunati), dove i FOR EACH STATEMENTtrigger possono vedere virtuale OLDe NEWtabelle. Questo non è possibile nelle attuali versioni di PostgreSQL, quindi è necessario utilizzare i FOR EACH ROWtrigger.
Qualcuno prima ha provato questo?
Ovviamente. È un uso piuttosto standard per i trigger, insieme a auditing, controllo di integrità, ecc.
Ti consigliamo di guardare in LISTENe NOTIFYper un buon modo per riattivare il lavoratore in caso di modifiche alla tabella compito accadere.
Stai già facendo la cosa più importante evitando di parlare con sistemi esterni direttamente dai trigger. Ciò tende ad essere problematico per prestazioni e affidabilità. Le persone spesso cercano di fare cose come inviare posta direttamente da un trigger, e questa è una brutta notizia.