Historically, @PostgreSQL resisted planner hints. Commercial forks and competitors sprout them, due to popular demand. In some sense, they are an admission of failure of the SQL project, and a step back to CODASYL DML. Know of a better plan? Then help us teach the planner!
-
Show this thread
-
A friend pointed out that this position would only be possible in academia and open source. And yet on less theoretical matters, we sprout features that users demand (or write patches for) all the time, while some other systems limp along with user-hostile tools.
1 reply 1 retweet 1 likeShow this thread -
But... for
#PostgreSQL 12 we have painted ourselves into a corner. Everybody knows that CTE (WITH) queries are "optimisation fences" today, aways "materialised" (it even says so in various ways in the manual). And yet we really want to be able to inline them.2 replies 2 retweets 2 likesShow this thread -
Replying to @MengTangmu
I don't think the corner is as big as you, and others, make it out to be. Pragmatically, a lot of the dangers of hints (react poorly to upgrades, data distribution changes, ...) aren't present for an explicit flag whether CTEs are inlinable.
1 reply 0 retweets 1 like
We've been pragmatic in this area before, c.f. hacks around keeping OFFSET 0 a barrier, even when other OFFSET cases get optimized. Explicit CTE barrierness has less downsides than the OFFSET 0 business.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.