Tom Lane wrote:
>
>There is probably some minuscule cost difference involved --- you save
>parsing and parse analysis of a long query string. On the other hand,
>you pay to pull the view definition from the catalogs and merge it into
>the given query. I'd not care to hazard a guess on whether the actual
>net cost is more or less; but in any case these costs will be swamped
>by query planning and execution, if the query is complex.
>
Actually, there are cases when a view can impact performance.
If you are joining a view, it seems to be treated as a subquery, that
might have a much larger result than you would like.
Imagine
SELECT something
FROM A JOIN B JOIN C ...
WHERE A.primaryKeyFoo=1234 ...
where C is a view, containing JOINs itself, I observed a query plan
(7.3.2) like
A JOIN B JOIN (D JOIN E)
instead of
A JOIN B JOIN D JOIN E which would be much more efficient for the
A.primaryKeyFoo restriction.