Re: CTE optimization fence on the todo list?

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: CTE optimization fence on the todo list?
Дата
Msg-id 5544055E.6070308@pgmasters.net
обсуждение исходный текст
Ответ на Re: CTE optimization fence on the todo list?  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 5/1/15 6:32 PM, Peter Geoghegan wrote:
> On Fri, May 1, 2015 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Assuming that that sketch is accurate, it would take more code to provide
>> a new user-visible knob to enable/disable the behavior than it would to
>> implement the optimization, which makes me pretty much -1 on providing
>> such a knob.  We should either do it or not.  If we do, people who want
>> optimization fences should use the traditional "OFFSET 0" hack.
>
> +1

Not sure if I'm thrilled with the "OFFSET 0" hack but I guess it's not
much different from the CTE hack I've been using.

An "enable_cte_optimization" GUC would serve to keep old code from
breaking while giving new users/queries the advantage of optimization.

I'm not sure it's worth adding the complexity, though.  In my experience
not that many developers use CTEs.

--
- David Steele
david@pgmasters.net


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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Reducing tuple overhead
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Improving replay of XLOG_BTREE_VACUUM records