| From: | Martin Foster <martin(at)ethereal-realms(dot)org> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: Faster with a sub-query then without | 
| Date: | 2004-08-15 16:01:26 | 
| Message-ID: | 411F88D6.3000300@ethereal-realms.org | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Tom Lane wrote:
> Martin Foster <martin(at)ethereal-realms(dot)org> writes:
> 
>>The one not using sub-queries under EXPLAIN ANALYZE proves itself to be 
>>less efficient and have a far higher cost then those with the penalty of 
>>a sub-query.   Since this seems to be counter to what I have been told 
>>in the past, I thought I would bring this forward and get some 
>>enlightenment.
> 
> 
> The ones with the subqueries are not having to form the full join of W
> and G; they just pick a few rows out of G and look up the matching W
> rows.
> 
> The "subquery penalty" is nonexistent in this case because the
> subqueries are not dependent on any variables from the outer query, and
> so they need be evaluated only once, rather than once per outer-query
> row which is what I suppose you were expecting.  This is reflected in
> the EXPLAIN output: notice they are shown as InitPlans not SubPlans.
> The outputs of the InitPlans are essentially treated as constants (shown
> as $0 in the EXPLAIN output) and the outer plan is approximately what
> it would be if you'd written WHERE g.field = 'constant' instead of
> WHERE g.field = (select ...)
> 
> 			regards, tom lane
That would explain it overall.  Still, it does seem unusual when one 
puts in additional code, which most literature warns you about and you 
actually gain a speed boost.
Thanks!
	Martin Foster
	Creator/Designer Ethereal Realms
	martin(at)ethereal-realms(dot)org
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-08-15 17:21:30 | Re: Slow joins against set-returning functions | 
| Previous Message | Michael Fuhr | 2004-08-15 16:00:14 | Slow joins against set-returning functions |