From: | Blagoj Petrushev <b(dot)petrushev(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Trigger concurrent execution |
Date: | 2014-05-16 00:06:06 |
Message-ID: | CAKe+-76yWqD=Wv9ifvPEp59r7=KZUJqG7zvO7zmc3PS==VF2+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I'm thinking of an extension to trigger functionality like this:
CREATE TRIGGER trigger_name
AFTER event
ON table
CONCURRENTLY EXECUTE PROCEDURE trigger_fc
This would call the trigger after the end of the transaction.
The following is a use-case, please tell me if I'm doing it wrong.
I have a big table with big text column article and a nullable
tsvector column fts_article. On each insert or update that changes the
article, I trigger-issue 'NOTIFY article_changed row_id', then, with a
daemon listener, I catch the notification and update fts_article
accordingly with my_fts_fc(article). The reason I don't do this
directly in my trigger is because my_fts_fc is slow for big articles,
fts_article has a gin index, and also, on heavy load, my listener can
do these updates concurrently. Now, with a concurrent execution of
triggers, I can just call my_fts_fc inside the trigger instead of the
notify roundtrip.
Kind regards,
Blagoj Petrushev
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-05-16 00:10:40 | Re: 9.4 release notes |
Previous Message | Tomas Vondra | 2014-05-15 23:47:16 | Re: buildfarm animals and 'snapshot too old' |