Thread: view selection during query rewrite
Suppose I have the following query and a view v1 defined as follows:
Q1: SELECT * FROM Table1 WHERE Table1.col1 = 5 and Table1.col2 LIKE '%abc%';
create view v1 as select * from Table1 where Table1.col1 = 5;
An effective way to execute Q1 would be to re-write it as: select * from v1 where col2 LIKE '%abc%'; provided that the selection predicates are highly selective and also if it is cheaper in execution time of the query.
However I see that postgres does not automatically perform query rewriting using view. I have looked at the plan using explain (analyze) and I see that Q1 is always executed using the base tables unless I explicitly mention the view in the query instead of the base table.
Is there a way to enforce automatic view selection in postgres or is it up to the user to write the query optimally?
Vamsi Meduri <vamsikrishna1902@gmail.com> writes:
> Suppose I have the following query and a view v1 defined as follows:
> *Q1: SELECT * FROM Table1 WHERE Table1.col1 = 5 and Table1.col2 LIKE
> '%abc%';*
> *create view v1 as select * from Table1 where Table1.col1 = 5;*
> An effective way to execute Q1 would be to re-write it as: *select * from
> v1 where col2 LIKE '%abc%';* provided that the selection predicates are
> highly selective and also if it is cheaper in execution time of the query.
> However I see that postgres does not automatically perform query rewriting
> using view. I have looked at the plan using explain (analyze) and I see
> that Q1 is always executed using the base tables unless I explicitly
> mention the view in the query instead of the base table.
If you are talking about a regular view, such a transformation would be a
complete waste of time, because the end result would be exactly the same
(after expending a lot of cycles transforming the query and then reversing
it back to the original state during view expansion).
If it's a materialized view, then there'd be a potential for savings ...
but the other side of that coin is that you'd get stale data, since
a matview is not going to be entirely up to date. It's no business of
the rewriter (or the query planner) to decide that such a tradeoff is OK.
I do recall some discussion of extensions attempting to do such things,
but I doubt we'd ever put it in core Postgres.
regards, tom lane