Re: Faster with a sub-query then without

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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Martin Foster
Дата:
Сообщение: Faster with a sub-query then without
Следующее
От: Michael Fuhr
Дата:
Сообщение: Slow joins against set-returning functions