From: | "Gordon A(dot) Runkle" <gar(at)integrated-dynamics(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: UNION in a VIEW? |
Date: | 2001-04-05 13:30:18 |
Message-ID: | 9ahrl7$1aih$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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2001-04-05 14:29:42 | Re: Re: UNION in a VIEW? |
Previous Message | Tim Perdue | 2001-04-05 12:52:50 | Re: Memory and performance |