From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | vadim(at)sable(dot)krasnoyarsk(dot)su (Vadim B(dot) Mikheev) |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: subselects |
Date: | 1998-01-21 15:29:57 |
Message-ID: | 199801211529.KAA20977@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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(at)candle(dot)pha(dot)pa(dot)us
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-01-21 15:34:45 | Re: [PORTS] -current version won't initdb under i386_solaris... |
Previous Message | The Hermit Hacker | 1998-01-21 15:18:29 | Re: [HACKERS] Re: subselects |