Well, I havn't run the rule so I don't know exactly whether it is relevent, but simply put, RULEs are like *macro substitution*. In macros, if you specify an expression (like a view) as an argument, it is placed as a whole each place the argument is used. UPDATEs for different tables cannot be merged into a single query so you get four queries and it's not clear how you could avoid any work. I guess each subquery may be optimised individually, though I don't know if it really helps. Perhaps you could show us the resulting query plans and how you think they could be improved. Have a nice day, On Wed, May 25, 2005 at 10:40:38AM +0200, Sebastian Böck wrote: > Thank you for the explanation. That's what I wanted to do first, but > then I discovered that the view gets not only evaluated for every rule > on it, but also gets evaluated as often as there are statements in one > rule. > > Example: > > CREATE OR REPLACE RULE upd AS ON UPDATE TO view_test > DO INSTEAD ( > UPDATE test SET test = NEW.test WHERE id = OLD.id; > UPDATE join1 SET text1 = NEW.text1 WHERE id = OLD.id; > UPDATE join2 SET text2 = NEW.text2 WHERE id = OLD.id; > UPDATE join3 SET text3 = NEW.text3 WHERE id = OLD.id; > ); > > Why gets the view evaluated 4 times? > > Thanks > > Sebastian -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment:
pgpVtOprfjXTr.pgp
Description: PGP signature
