Vamsi Meduri <vamsikrishna1902@xxxxxxxxx> 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
