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

From David G. Johnston
Subject Re: [HACKERS] CTE inlining
Date
Msg-id CAKFQuwayrvy8F00DJh-P-PXMG7Vjv3Qzb=o-gr89s=SjZ_OZ=w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: [HACKERS] CTE inlining  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson <andreas@proxel.se> wrote:
On 05/01/2017 04:17 PM, David Fetter wrote:
Maybe we could allow a "decorator" that would tell the planner the CTE
could be inlined?

    WITH INLINE mycte AS ( ...)

+1 for a decorator, -1 for this one.

I am not sure I like decorators since this means adding an ad hoc query hint directly into the SQL syntax which is something which I requires serious consideration.

​Given that we already have
​"​
prevent optimization
​"​
syntax why do we need a decorator on the CTE?
 


We already have an explicit optimization fence with OFFSET 0, and I
think making optimization fences explicit is how we should continue.
I'd be more in favor of something along the lines of

    WITH FENCED        /* Somewhat fuzzy.  What fence? */
    or
    WITH AT_MOST_ONCE  /* Clearer, but not super precise */
    or
    WITH UNIQUE_ATOMIC /* More descriptive, but not super clear without the docs in hand */

or something along that line.

What about WITH MATERIALIZED, borrowing from the MySQL terminology "materialized subquery"?

​I would shorten that to "WITH MAT" except that I don't think that having two way to introduce an optimization fence is worthwhile.

If we don't optimize SRFs-in-target-list, and thus avoid multiple function evaluation for (composite_col).*, I believe a significant number of intentional optimization fence uses will be safe but behavioral changes.

David J.

pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: [HACKERS] CTE inlining
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping