On Tue, Jul 24, 2018 at 07:57:49PM -0400, Tom Lane wrote: > Andres Freund <and...@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.
It is widely known that CTEs in PG are optimizer barriers. That actually is useful, and I do make use of that fact (though I'm not proud of it). My proposal is that PG add an extension for specifying that a CTE is to be materialized (barrier) or not (then inlined). Nico --
