From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: rules: evaluate inputs in advance |
Date: | 2006-05-14 06:01:39 |
Message-ID: | 1147586499.4851.8.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Martijn,
On Fri, 2006-05-12 at 18:05 +0200, Martijn van Oosterhout wrote:
> But it can't really. In the example that started this thread, there are
> two seperate rules and after rewriting the executor will be presented
> two seperate queries.
Ah, thank you, that explains the difficulties with rules.
> What you probably want is a function that is given the row and then
> executes the two statements on a per row basis. This has the effect you
> want but gives up the major benefit of rules, wholesale query
> restructuring like views which allows the executor to find better
> plans. The executor can't see inside a trigger so it can't optimise.
Isn't that an argument for keeping rewrite rules instead of using
something trigger like for updatable views? Wouldn't it be feasible to
teach the executor how to handle multiple queries with some
pre-evaluated input?
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Lincoln Yeoh | 2006-05-14 08:31:00 | Re: [PERFORM] Arguments Pro/Contra Software Raid |
Previous Message | Ed L. | 2006-05-14 04:27:26 | pg_dump index/constraint creation order |