terry@chosen-ones.org (Terry Lee Tucker) writes:
> Lately, I've begun using views quite often especially when queries for various
> reports, etc. become complicated. I am now wondering if there is a price to
> pay in terms of overhead for this. In truth, I don't really understand how a
> view works. I know that it takes on many of the attributes of a table, but is
> it a table? Is the data pulled together when one selects from the view or is
> it maintained as a table all along. Guidance to the ignorant appreciated...
Under the hood, views represent a rewriting of the query.
http://www.postgresql.org/docs/8.4/static/rules-views.html
If you have two tables that are joined together, in a view, then when
you query the view, you're really running a more complex query than
you're seeing, namely one that joins together the two tables, and does
whatever else you put into your query.
It *looks* like a table, for almost all intents and purposes, but what
it is, really, is a structure that leads to your queries being rewritten
to access the *real* tables that underly the view.
So the date is, as you suggest, "pulled together when one selects from
the view."
--
output = reverse("moc.liamg" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/slony.html
"People are more vocally opposed to fur than leather because it's
easier to harass rich women than motorcycle gangs." [bumper sticker]