| From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
|---|---|
| To: | Kenneth Downs <ken(at)secdat(dot)com> |
| Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: background triggers? |
| Date: | 2006-05-24 12:29:51 |
| Message-ID: | 1148473793.20217.128.camel@model.home.waw.pl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, 2006-05-24 at 07:41 -0400, Kenneth Downs wrote:
> >
> Why not have the INSERT go to an "inbox" table, a table whose only job
> is to receive the data for future processing.
Actually, it 'sort of' works that way.
> Your client code should mark all rows with a batch number as they go
> in. Then when the batch is loaded, simply invoke a stored procedure to
> process them. Pass the stored procedure the batch number.
If I have that stored procedure and if I issue command that would launch
such stored procedure from "psql>" prompt: how long will I have to wait
for another prompt? 1) until the procedure ends its job. 2) right away,
the procedure does its job unabidedly 'in the background'.
My impression was, that I get the next prompt after the procedure
finishes, so it wouldn't be a solution. But if (2) applies, that is
really it.... Frankly, it would take me some time to get back to those
sources (and generate simulation data) - so anybody knows the answer?
-R
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2006-05-24 12:32:34 | Re: compiling source code!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| Previous Message | Richard Huxton | 2006-05-24 12:26:57 | Re: Clearing out old idle connections |