Re: Early WIP/PoC for inlining CTEs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Jeremy Finzel <finzelj@gmail.com>,
Andrew Gierth <andrew@tao11.riddles.org.uk>,
pgsql-hackers@postgresql.org
Date: 2018-07-24T23:57:49Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Prevent inlining of multiply-referenced CTEs with outer recursive refs.
- 9476131278c7 12.0 landed
-
Allow user control of CTE materialization, and change the default behavior.
- 608b167f9f9c 12.0 landed
-
Split QTW_EXAMINE_RTES flag into QTW_EXAMINE_RTES_BEFORE/_AFTER.
- 18c0da88a5d9 12.0 landed
-
document when PREPARE uses generic plans
- fab9d1da4a21 9.6.0 cited
Andres Freund <andres@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. regards, tom lane