Re: Early WIP/PoC for inlining CTEs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Early WIP/PoC for inlining CTEs
Дата
Msg-id 21958.1532476669@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Early WIP/PoC for inlining CTEs  (Andres Freund <andres@anarazel.de>)
Ответы Re: Early WIP/PoC for inlining CTEs  (Andres Freund <andres@anarazel.de>)
Re: Early WIP/PoC for inlining CTEs  (Nico Williams <nico@cryptonector.com>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-07-24 19:49:19 -0400, Tom Lane wrote:
>> However, a singly-referenced SELECT CTE could reasonably be treated as
>> equivalent to a sub-select-in-FROM, and then you would have the same
>> mechanisms for preventing inlining as you do for those cases,
>> e.g. OFFSET 0.  And sticking in OFFSET 0 would be backwards-compatible
>> too: your code would still work the same in older releases, unlike if
>> we invent new syntax for this.

> I still think this is just doubling down on prior mistakes.

Not following what you think a better alternative is?  I'd be the
first to agree that OFFSET 0 is a hack, but people are used to it.

Assuming that we go for inline-by-default for at least some cases,
there's a separate discussion to be had about whether it's worth
making a planner-control GUC to force the old behavior.  I'm not
very excited about that, but I bet some people will be.

            regards, tom lane


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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [HACKERS] plpgsql - additional extra checks
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Early WIP/PoC for inlining CTEs