Table Level Replication Via Triggers
От | Stef telford |
---|---|
Тема | Table Level Replication Via Triggers |
Дата | |
Msg-id | 20000804181623.E003B1F3D2@chronozon.dyndns.org обсуждение исходный текст |
Список | 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 по дате отправления: