Re: UNION in a VIEW?

From: "Gordon A(dot) Runkle" <gar(at)no-spam-integrated-dynamics(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: UNION in a VIEW?
Date: 2001-04-04 23:57:47
Message-ID: 9agc20$v7h$1@news.tht.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

In article <web-34027(at)davinci(dot)ethosmedia(dot)com>, "Josh Berkus"
<josh(at)agliodbs(dot)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

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Gerald Gutierrez 2001-04-05 00:24:12 RE: RE: serial type; race conditions
Previous Message Gordon A. Runkle 2001-04-04 23:41:26 Re: UNION in a VIEW?