Table Level Replication Via Triggers - Mailing list pgsql-interfaces

From Stef telford
Subject Table Level Replication Via Triggers
Date
Msg-id 20000804181623.E003B1F3D2@chronozon.dyndns.org
Whole thread Raw
List pgsql-interfaces
hello everyone,
well, its been a fun 48hours here and no mistake. It appears that
a view that I created now takes too long to process on the current
database
here (its not my fault ;). Many screaming people and clients all running
about and cursing. 
So. I decided that the fix was to logically seperate the historical
data from the live data (yes, it was 'requested' that the database be
designed
that way, but I am rapidly in the course of changing it ;).
Now, i have no problem with designing Triggers to fire off
inserts/updates
into the new (non-historical) tables, to keep them fresh as it were, and
doing the
view on those tables instead. This way, i dont have 7-10 million old
historical
records to process during the 'view's runtime. 
it will hopefully make things smoother (that and I also noticed that
the
'programmer' who wrote the perl code that deals with the select returns
doesnt use cursors
but perl structures to do it *ugh*!). The question therefore is:
what is the best/quickest way to achieve Table Level replication ?
i, as i said above, am thinking of having copies of all the tables and
making them 'non-historical' and then building the view on them instead.
Can 
this work across database instances ?! 
Thanks for your thoughts and comments on this. I am ~so~ annoyed
at the previous database designer, that you can hear my teeth grinding
across
the atlantic.
(oh. one last question, totally unrelated, is it possible to add in
custom tags 
in the HTML output from a select ?! jst a passing thought for more speed
if i can do that ;)
Many thanks and deepest regards,Stefs


pgsql-interfaces by date:

Previous
From: "David Lloyd-Jones"
Date:
Subject: Re: Python + PostgreSQL
Next
From: Bob Kline
Date:
Subject: Re: Python + PostgreSQL