Re: [HACKERS] CTE inlining - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] CTE inlining
Date
Msg-id CAKFQuwYpQ0XoyEWaxQtDY+soaSZhPoLr_SxFizgaEakfiT_=cw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] CTE inlining  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Stas Kelvich
Date:
Subject: Re: [HACKERS] Logical replication ApplyContext bloat
Next
From: Erik Rijkers
Date:
Subject: Re: [HACKERS] snapbuild woes