Re: [SQL] Subselect performance

> On Tue, 21 Sep 1999, Tom Lane wrote:
> 
> > Daniel Lopez <ridruejo@atm9.com.dtu.dk> writes:
> > > $list = select d from c
> > > select b from a where b in ( $list )
> > > is  5 seconds
> > 
> > > select b from a where b in (select d from c) 
> > > is 3 minutes!!  (although it should be at least as fast as a)!
> > 
> > Not necessarily.  Your first example is depending on the fact that
> > the "list" (number of values selected from c) is short.  Try it with
> > 10000 or 100000 values from c, if you want to see the backend crash ;-)
> 
> I've encoutered this sort of issue myself where I just wanted the
> sub-select to be performed once.  Granted it would not work if you wanted
> to select 10000 or 100000 but what if you have a very larged table a and a
> very small table c (using the example above).  As you pointed out,
> currently you're looking at 'a x c' runtime... Ugh indeed; whereas just
> executing the subselect once and cut and pasting that you have an order of
> 'a' runtime...

OK, I am jumping in here, because it seems we have some strange
behavour.

The only subselect problem I know of is that:
select b from a where b in (select d from c) 

will execute the subquery just once, but will do a sequential scan for
of the subquery results for each row of 'a' looking for 'b' that is in
the set of result rows.

This is a major performance problem, one that is known, and one that
should be fixed, but I am sounding like a broken record.

The solution is to allow the subquery results to be mergejoined(sorted),
or hashjoined with the outer query.

Am I correct, or is something else going on here?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026