Re: UNION in a VIEW? - Mailing list pgsql-sql

From Gordon A. Runkle
Subject Re: UNION in a VIEW?
Date
Msg-id 9ahrl7$1aih$1@news.tht.net
Whole thread Raw
In response to Re: UNION in a VIEW?  ("Josh Berkus" <josh@agliodbs.com>)
Responses Re: Re: UNION in a VIEW?
List pgsql-sql
In article <web-34027@davinci.ethosmedia.com>, "Josh Berkus"
<josh@agliodbs.com> wrote:

> Tom, Gordon,
> Hmmm ... I'm pretty used an external WHERE clause being applied to the
> output of the view, rather than pushed down into the member selects of
> the UNION, in the same way as if the UNION query were a subselect.
> Coming from a SQL Server background, I'd actually find the suggested
> behavior rather confusing (as well as tough for you guys to implement).

Like I said, I'm not a backend guru.  However, SQL Server and DB2
both *appear* to be pushing down the WHERE clause.  They may not be,
but they both process the query nearly instantaneously on large
tables, which leads me to speculate that they do.  PostgreSQL goes
off and munches for a *long* time on the same view/query, whereas if
I write a query which explicitly distributes the WHERE then PostgreSQL
processes the query very fast (faster than DB2 or SQL Server).

So, I can only guess what's happening "behind the curtain", but this
is what I'm observing.

Plus, I think that if the WHERE clause were applied to the results
of the VIEW, that would require storing those results in temp space,
and for large tables would be very slow.  I believe that's the whole
reason that VIEWs' underlying queries can be merged/rewritten with
the "calling" query?

Thanks,

Gordon.
-- 
It doesn't get any easier, you just go faster.  -- Greg LeMond


pgsql-sql by date:

Previous
From: Tim Perdue
Date:
Subject: Re: Memory and performance
Next
From: Kyle
Date:
Subject: Project Development