Skip site navigation (1) Skip section navigation (2)

union optimization in views

From: "JOE" <joe(at)piscitella(dot)com>
To: <pgsql-sql(at)postgresql(dot)org>
Subject: union optimization in views
Date: 2002-08-29 04:47:20
Message-ID: 003d01c24f17$2d21ff00$c801a8c0@joe (view raw or flat)
Thread:
Lists: pgsql-sql
We are attempting to move a couple of systems from Oracle to Postgres but can not do so without application rewrites due to the current use of views with UNIONs and the criticality of the performances of these views.

I was wondering if a decision has been made on the optimization with the UNION clause in views.  There are many documents in the SQL archive showing that the "push down" is not occuring and thus the use of UNION's in views is limited to case where the data set is small or performance is not a consideration.  I also looked through the TODO list and didn't see anything (of course I could have missed references).  

thanks - Joe

snip of an Article from SQL archives

 CREATE VIEW two_tables AS
 SELECT t1.id, t1.name, t1.abbreviation, t1.juris_id
 FROM t1
 UNION ALL
 SELECT t2.id, t2.name, NULL, t2.juris_id
 FROM t2;

This works fine as a view, since I have made the id's unique between 
 the two  tables (using a sequence).   However, as t1 has 100,000 records, it is
vitally important that queries against this view use an index.
As it is a Union view, though, they ignore any indexes:

> It's probably not pushing the login='asdadad' condition down into the 
> queries in the view so it's possibly doing a full union all followed 
> by the condition (given that it's estimating a larger number of rows 
> returned).  I think there was some question about whether it was safe 
> to do that optimization (ie, is select * from (a union [all] b) where 
> condition always the same as
>  select * from a where condition union [all]
>  select * from b where condition
> )
>
> There wasn't any final determination --- it's still an open issue 
> whether there are any limitations the planner would have to consider 
> when trying to push down conditions into UNIONs.  Offhand it seems to 
> me that the change is always safe when dealing with UNION ALL, but I'm

> not quite convinced about UNION.  And what of INTERSECT and EXCEPT?
>
> Another interesting question is whether there are cases where the 
> planner could legally push down the condition, but should not because 
> it would end up with a slower plan.  I can't think of any examples 
> offhand, but that doesn't mean there aren't any.


Responses

pgsql-sql by date

Next:From: Bruce MomjianDate: 2002-08-29 05:03:05
Subject: Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Previous:From: Robert TreatDate: 2002-08-29 02:29:14
Subject: Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group