The reason why the client application would have to wait is because the
front-end is written in MSAccess. While Windows supports multi
threading, Access does not support multi threading.
(Multi threading allows background processing, IYDK)
Kenneth Downs wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org