Re: Faster with a sub-query then without
От | Martin Foster |
---|---|
Тема | Re: Faster with a sub-query then without |
Дата | |
Msg-id | 411F88D6.3000300@ethereal-realms.org обсуждение исходный текст |
Ответ на | Re: Faster with a sub-query then without (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane wrote: > Martin Foster <martin@ethereal-realms.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@ethereal-realms.org
В списке pgsql-performance по дате отправления: