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 по дате отправления:

Предыдущее
От: Michael Fuhr
Дата:
Сообщение: Slow joins against set-returning functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Slow joins against set-returning functions