> BTW: You might want to take a look at the new documentation
> of the rule system to understand how views work in detail.
>
I think I'll do that. I'd love to be able to help you for the rule
rewrite for v6.5 .
> It could only be the parse stage. After the rule system is
> through with the query, the parsetree given to the optimizer
> is exactly the same as if you typed in the query that
> accesses the real tables. Having a view
>
> CREATE VIEW v1 AS SELECT t1.a, t2.b FROM t1, t2
> WHERE t1.a = t2.a;
>
> and doing a
>
> SELECT * FROM v1 WHERE a = 'something';
>
> is 100% the same as
>
> SELECT t1.a, t2.b FROM t1, t2
> WHERE t1.a = 'something'
> AND t1.a = t2.a;
>
> The optimizer will get exactly the same parsetree and will
> generate the same plan then. So the timing difference cannot
> be in the optimizer or executor.
>
> But it's interesting. I'll do some tests on it and try to
> find out whether parsing of complicated WHERE clauses is that
> costly that it can be the reason. Seems the rule system is
> quicker than the parser :-)
>
What kind of speed increases are people seeing in their queries?
I've actually never created a view in PostgreSQL (say he with head hung
low).
> Jan
-DEJ
