Re: Early WIP/PoC for inlining CTEs

Andreas Karlsson <andreas@proxel.se>

From: Andreas Karlsson <andreas@proxel.se>

To: David Fetter <david@fetter.org>

Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Pg Hackers <pgsql-hackers@postgresql.org>

Date: 2018-10-04T09:22:32Z

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 10/03/2018 05:57 PM, David Fetter wrote:
> Is there any meaningful distinction between "inlining," by which I
> mean converting to a subquery, and predicate pushdown, which
> would happen at least for a first cut, at the rewrite stage?

Sorry, but I do not think I understand your question. The ability to 
push down predicates is just one of the potential benefits from inlining.

Andreas