Search Postgresql Archives

Re: background triggers?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux