Re: [HACKERS] CTE inlining

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] CTE inlining
Дата
Msg-id CAKFQuwYpQ0XoyEWaxQtDY+soaSZhPoLr_SxFizgaEakfiT_=cw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] CTE inlining  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] CTE inlining  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, May 9, 2017 at 12:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Also, considering that this behavior has been there since 8.4,
I think it's sheerest chutzpah to claim that changing the docs in
v10 would materially reduce the backward-compatibility concerns
for whatever we might do in v11.

​No it won't, but those who are using 10 as their first version would probably be happy if this was covered in a bit more depth.  Even a comment like "Unlike most other DBMS PostgreSQL presently executes the subquery in the CTE​ in relative isolation.  It is suggested that you document any intentional usage of this optimization fence as a query planning hint so that should the default change in the future you can update the query to support whatever official syntax is implemented to retain this behavior.

We cannot really help those who have been using this since 8.4 and won't read the relevant docs because they don't need to learn anything new; but we can at least avoid subjecting newer customers.  I'm not that strongly in favor of it but it would be a nice touch - even if it won't change the risk/reward calculation in any meaningful way.

David J.

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

Предыдущее
От: Stas Kelvich
Дата:
Сообщение: Re: [HACKERS] Logical replication ApplyContext bloat
Следующее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] snapbuild woes