> On Tuesday, 5 January, 2016 08:33, gunnar <gharms at hiqinvest.nl> said:
> Regarding views, I don't know how sqlite handles them but I know that > they can drastically slow down queries in MySQL for example. While this is true in many cases, using a view rather than a select on the underlying table should not incur any overhead provided that the view is a "simple projection". If the view generates a non-trivial projection such that those conditions must be maintained (materialized) in the query plan with respect to the view visitation, then the view will adversely affect performance. Simple projections should be flattened by the optimizer as if the original query had been phrased directly against the underlying tables. So, if there are no grouping, ordering, or outer join operations in the view, it will probably not affect the plan. If there are, then the view will itself become a "subselect" which must be visited as if it were a table. WHERE conditions, in simple projections and equijoins can be simply pushed out into the overall constraints. explain query plan will make this apparent.
