Re: SOLVED - RE: Poor performance using CTE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SOLVED - RE: Poor performance using CTE
Дата
Msg-id 15381.1353446809@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SOLVED - RE: Poor performance using CTE  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Список pgsql-performance
Jon Nelson <jnelson+pgsql@jamponi.net> writes:
> ... Perhaps even including a
> small blurb about what an optimization barrier even means (my
> understanding is that it merely forces materialization of that part of
> the query).

FWIW, it has nothing to do with materialization; it means that we don't
push conditions down into that subquery, nor pull subexpressions up out
of it, nor rearrange join order across the subquery boundary.  In short
the subquery is planned separately from the outer query.  But it could
then be run by the executor in the usual tuple-at-a-time fashion,
without materializing the whole subquery result.

It is true that CTEScan nodes materialize the subquery output (ie copy
it into a tuplestore), but that's to support multiple CTEScans reading
the same CTE.  One of the optimizations we *should* put in place
sometime is skipping the tuplestore if there's only one CTEScan on the
CTE.

            regards, tom lane


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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE