On 11/3/07, Tom Lane wrote:
> "Jeff Larsen" <[EMAIL PROTECTED]> writes:
> > My case probably fits the 'special case' description. Not all the
> > columns in each subquery matched up, so there were NULL::text
> > placeholders in some spots in the SELECT. In the case where
> > performance got bad, on
[[ Oops, still not used to gmail. Accidentally posted this straight to
Tom and not the list]]
> There are a bunch of special cases where it can't do that, though.
> Look into src/backend/optimizer/path/allpaths.c, particularly
> subquery_is_pushdown_safe:
My case probably fits the 'special case'
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Jeff Larsen wrote:
>> If it's possible to consider this abstractly, is there any particular
>> reason why there is such a vast difference in performance?
> That's surprising. The planner knows how to push down WHERE conditions
> to parts of a UNION
Jeff Larsen wrote:
Performance on
SELECT * from VIEW_X WHERE ;
was absolutely terrible. But performance on
SELECT * from VIEW_A WHERE
UNION ALL
SELECT * from VIEW_B WHERE
UNION ALL
SELECT * from VIEW_C WHERE ;
was nice and speedy, perhaps 100 times faster than the first.
If it's possible t
Jeff Larsen wrote:
If it's possible to consider this abstractly, is there any particular
reason why there is such a vast difference in performance? I would
guess that is has something to do with how the WHERE conditions are
applied to a view composed of a UNION of queries. Perhaps this is an
oppo
Consider:
CREATE VIEW_X AS
SELECT
UNION ALL
SELECT
UNION ALL
SELECT ;
versus
CREATE VIEW_A AS
SELECT ;
CREATE VIEW_B AS
SELECT ;
CREATE VIEW_C AS
SELECT ;
where , and are each somewhat complex
with several joins, but utilizing different tables for each of A, B
and C.
Performance on
SELE
