Re: update tables in remote db using trigger

Hi Rod,

This sounds nifty, but I'm wondering about the speed of such an operation.
Our design calls for a system that can do this one operation (over and
above all the other DB queries) 28 times per second.

What sort of performance are you getting out of this setup. Could it
handle 28 calls per second without bringing the system to it's knees?

Marc

Rod Taylor wrote:

> Simplest way I know of is to write a C function which fires off a
> shell script which in turn executes psql with appropriate parameters.
> The C function can pass it individual variables, or the entire SQL
> string.
>
> The reason for the shell script is that way the database, port, etc.
> are easy to change and don't require a re-compile / reload.
>
> One thing you definately cannot do is a C function which creates a new
> database connection on it's own. Doesn't like that at all!
>
> I've implemented a form of 'su' for postgres doing that -- makes a
> second connection back into the database. A middle man shell script
> ensures that only a few specific requests can be made (one is actually
> creating a system user with very specific parameters).
> --
> Rod Taylor
>
> There are always four sides to every story: your side, their side, the
> truth, and what really happened.
> ----- Original Message -----
> From: "Marc Wrubleski" <mlwruble(at)sorexsoftware(dot)com>
> To: <pgsql-general(at)postgresql(dot)org>
> Sent: Friday, April 06, 2001 7:22 PM
> Subject: [GENERAL] update tables in remote db using trigger
>
> > Hi all,
> >
> > I would like to do something like the following in a trigger:
> >
> > update tablename on otherdbhost set field1 = new.field1 where
> keyfield =
> > new.keyfield;
> >
> > Is this a pipe dream using Postgres or is there some way to perform
> such
> > a feat?
> >
> > Thanks.
> >
> > Marc Wrubleski
> >
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >