Re: background triggers?

Sim Zacks wrote:

> The problem with client code processing a function is that unless you
> are using threads (my client application is not in a multi-threaded
> environment), the client has to wait for the server to return from the
> end of the function. I don't want the client to wait and the result
> doesn't affect the user at all, so there is no reason why he should wait.

No reason for him to wait. Even Windows supports background processing
(geez I think so anyway).

If you are on Linux spawning a background process is a no-brainer,
there's plenty of ways to do it. There ought to be a way on windows I
would think.

>
> Kenneth Downs wrote:
>
>> Rafal Pietrak wrote:
>>
>>> A plain INSERT of batch takes 5-10minutes on desktop postgresql (800MHz
>>> machine, ATA disks). When I attach trigger (*Very* simple funciton) to
>>> update the accounts, the INSERT take hours (2-4). But when I make just
>>> one single update of all accounts at the end of the batch insert, it
>>> takes 20-30min.
>>>
>>>
>>>
>> Why not have the INSERT go to an "inbox" table, a table whose only
>> job is to receive the data for future processing.
>>
>> 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.
>>
>> IOW, have your "background trigger" be a stored procedure that is
>> invoked by the client, instead of trying to get the server to do it.
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match