|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andreas Karlsson <andreas(at)proxel(dot)se>|
|Cc:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, David Fetter <david(at)fetter(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Early WIP/PoC for inlining CTEs|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> Therefore, I'm reversing my previous opinion that we should not have
> an explicit NOT MATERIALIZED option. I think we should add that, and
> the behavior ought to be:
> * No option given: inline if there's exactly one reference.
> * With MATERIALIZED: never inline.
> * With NOT MATERIALIZED: inline regardless of the number of references.
> (Obviously, we should not inline if there's RECURSIVE or the CTE
> potentially has side-effects, regardless of the user option;
> I don't think those cases are up for debate.)
Hearing no immediate pushback on that proposal, I went ahead and made
a version of the patch that does it like that, as attached. I also took
a stab at documenting it fully.
I was interested to find, while writing the docs, that it's a real
struggle to invent plausible reasons to write MATERIALIZED given the
above specification. You pretty much have to have lied to the planner,
eg by making a volatile function that's not marked volatile, before
there's a real need for that. Am I missing something? If I'm not,
then we're in a really good place backwards-compatibility-wise,
because the new default behavior shouldn't break any cases where people
regards, tom lane
|Next Message||Marko Tiikkaja||2019-01-27 00:15:16||Re: Early WIP/PoC for inlining CTEs|
|Previous Message||Tom Lane||2019-01-26 19:19:00||Re: Alternative to \copy in psql modelled after \g|