Re: SOLVED - RE: Poor performance using CTE

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: SOLVED - RE: Poor performance using CTE
Дата
Msg-id 50A442A8.10803@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: SOLVED - RE: Poor performance using CTE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SOLVED - RE: Poor performance using CTE  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: SOLVED - RE: Poor performance using CTE  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-performance
On 11/15/2012 12:29 AM, Tom Lane wrote:
> David Greco <David_Greco@harte-hanks.com> writes:
>> Thanks, that did the trick. Though I'm still not clear as to why.
> PG treats WITH as an optimization fence --- the WITH query will be
> executed pretty much as-is.  It may be that Oracle flattens the query
> somehow; though if you're using black-box functions in both cases,
> it's not obvious where the optimizer could get any purchase that way.
>

I was looking through the latest spec drafts I have access to and
couldn't find any reference to Pg's optimisation-fence-for-CTEs
behaviour being required by the standard, though I've repeatedly seen it
said that there is such a requirement.

Do you know where it's specified?

All I can see is that the optimised result must have the same effect as
the original. That'd mean that wCTEs and CTE terms that use VOLATILE
functions or functions with side-effects couldn't be optimised into
other queries. Simple CTEs could be, though, and there are times I've
really wished I could use a CTE but I've had to use a set-returning
subquery to get reasonable plans.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: postgres 8.4, COPY, and high concurrency
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE