te...@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] -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
