| From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
|---|---|
| To: | Chris Browne <cbbrowne(at)acm(dot)org> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: background triggers? |
| Date: | 2006-05-23 16:44:55 |
| Message-ID: | 1148402696.20217.22.camel@model.home.waw.pl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, 2006-05-23 at 15:56 +0000, Chris Browne wrote:
> > The use that I have for this at the moment, and I can think of many
> > other uses, is that I want to populate a statistics table each time
> > that a table is updated. But the code to populate the table takes 10
> > seconds to run. I don't want the user to have to wait 10 seconds to
> > add a record.
>
> This seems a case for using NOTIFY/LISTEN.
>
> - You have a process connected to the database that runs LISTEN,
> causing it to listen for a particular message.
>
> LISTEN regen_statistics;
>
> - Your trigger submits a notification:
>
> NOTIFY regen_statistics;
Some time ago I fell into quite similair problem. But LISTEN/NOTIFY was
not a solution.
In that case I needed to *disconnect* and never bother about the outcome
of a long running background trigger.
So if I may re-phrase the question: "is there a way to have a trigger,
that, when launched, can check if it's already running in backgroung for
some other INSERT, return imediately if so, but turn into background for
a long-lasting job if not".
The functionality required is "lazy" update of agregate tables, which
need not be 100% acurate, but should be kept in-sync whenever possible.
-R
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bob Pawley | 2006-05-23 16:56:01 | Re: Interface |
| Previous Message | Tom Lane | 2006-05-23 16:14:31 | Re: Quering by Regular Expressions stored in table |