pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: JOE <joe@piscitella.com>
To: pgsql-sql@postgresql.org
Subject: union optimization in views
Date: Wed, 28 Aug 2002 21:47:20 -0700
Message-ID: <003d01c24f17$2d21ff00$c801a8c0@joe> (raw)

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.

view thread (3+ messages)  latest in thread

Message-ID: <003d01c24f17$2d21ff00$c801a8c0@joe>
Permalink:  ../003d01c24f17$2d21ff00$c801a8c0@joe/
Also on:    postgresql.org/message-id/003d01c24f17$2d21ff00$c801a8c0@joe

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: joe@piscitella.com
  Subject: Re: union optimization in views
  In-Reply-To: <003d01c24f17$2d21ff00$c801a8c0@joe>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox