Thread

1. subselects

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-21T03:24:11Z

   We are only going to have subselects in the WHERE clause, not in the
   target list, right?
   
   The standard says we can have them either place, but I didn't think we
   were implementing the target list subselects.
   
   Is that correct?
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us
   
   

2. Re: subselects

   Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-01-21T10:10:22Z

   Bruce Momjian wrote:
   > 
   > We are only going to have subselects in the WHERE clause, not in the
   > target list, right?
   > 
   > The standard says we can have them either place, but I didn't think we
   > were implementing the target list subselects.
   > 
   > Is that correct?
   
   Yes, this is right for 6.3. I hope that we'll support subselects in 
   target list, FROM, etc in future.
   
   BTW, I'm going to implement subselect in (let's say) "natural" way -
   without substitution of parent query relations into subselect and so on,
   but by execution of (correlated) subqueries for each upper query row
   (may be with cacheing of results in hash table for better performance).
   Sure, this is much more clean way and much more clear how to do this.
   This seems like SQL-func way, but funcs start/run/stop Executor each time
   when called and this breaks performance. 
   
   Vadim
   
   

3. Re: subselects

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-21T15:29:57Z

   > > Is that correct?
   > 
   > Yes, this is right for 6.3. I hope that we'll support subselects in 
   > target list, FROM, etc in future.
   
   OK.
   
   > 
   > BTW, I'm going to implement subselect in (let's say) "natural" way -
   > without substitution of parent query relations into subselect and so on,
   > but by execution of (correlated) subqueries for each upper query row
   > (may be with cacheing of results in hash table for better performance).
   > Sure, this is much more clean way and much more clear how to do this.
   > This seems like SQL-func way, but funcs start/run/stop Executor each time
   > when called and this breaks performance. 
   
   Sure, lets see how it performs.  Most correlated subqueries are very
   slow in commercial databases too.  I guess I thought you could do the
   whole subquery, then sort on the correlated columns, which allows quick
   access to the results, but if the subquery references only a small part
   of the upper query's output, it is quicker to do it your way.
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us