On Saturday, February 8, 2003, at 11:54 AM, Tom Lane wrote:
> "Eric B.Ridge" <ebr@tcdi.com> writes:
>> I'm just curious...
>> If you have a view:
<snip>
>> What, behind the scenes, actually happens?
>
> There's a pretty good description in the Programmer's Guide:
> http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/rules.html
>
> After reading that you can try looking at it for yourself. For
> example:
Tom, thanks for explaining this. Your explanation and the docs really
cleared things up. But I still have a few questions...
<snip>
>> Is the definition of "foo_view" looked up in the system catalog, query
>> rewritten, parsed, then executed?
>
> The Query representation is rebuilt from this textual form and then
> substituted into the referencing query. I wouldn't call that
> "parsing",
So the text form of the Query *is* looked up in pg_rewrite on every
use? Or is it looked up only once (per backend maybe?)? The docs
didn't say... unless I overlooked it.
> though --- the work of the parser phase is long over. See
> http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/
> overview.html
<snip>
> What the planner sees is practically indistinguishable from what it
> sees if you
> write out the view's definition as a sub-select like that. Exercise
> for
So what should be more efficient? Re-parsing/planning the entire SQL
string (w/ the "view" definition in-line) or actually using the view?
How much overhead is really involved in getting the "textual form" and
turning it into a Query?
I guess my real question is (from a pure performance standpoint): If
I'm trying to trim every last millisecond off query execution time,
should I be using views?
thanks!
eric
