Re: Early WIP/PoC for inlining CTEs
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Andreas Karlsson <andreas@proxel.se>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Tom Lane <tgl@sss.pgh.pa.us>, David Fetter <david@fetter.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-11T18:58:39Z
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
On Sat, Jan 12, 2019 at 7:19 AM Andres Freund <andres@anarazel.de> wrote: > On 2019-01-11 11:12:25 -0500, Robert Haas wrote: > > I actually think that we should go "all in" here and allow the user to > > specify either that they want materialization or that they don't want > > materialization. If they specify neither, then we make some decision > > which we may change in a future release. If they do specify > > something, we do that. > > +many I think the syntax as proposed is almost OK if we only want to grandfather in our historically hintful CTEs but discourage the development of any future kinds of hints. Even then I don't love the way it formalises a semi-procedural step at the same language level as a glorious declarative relational query. Maybe we could consider a more extensible syntax that is attached to the contained SELECT rather than the containing WITH. Then CTEs would be less special; there'd be a place to put hints controlling top-level queries, subselects, views etc too (perhaps eventually join hints, parallelism hints etc, but "materialize this" would be just another one of those things). That'd be all-in. -- Thomas Munro http://www.enterprisedb.com