3 ms·
Be warned that in PostgreSQL, WITH is an optimization barrier, and is planned to remain that way to serve that purpose. If you can, prefer using views to enhanc
by colanderman 7y ago
Be warned that in PostgreSQL, WITH is an optimization barrier, and is planned to remain that way to serve that purpose. If you can, prefer using views to enhance readability (and testability as a bonus). PostgreSQL views (unlike those in MySQL) do not prevent optimization across them.
- zkomp 7y agoNo, CTEs are not planned to remain a barrier, this is already fixed in the next version which is in feature freeze right now. https://www.depesz.com/2019/02/19/waiting-for-postgresql-12-allow-user-control-of-cte-materialization-and-change-the-default-behavior/ https://www.depesz.com/2019/02/19/waiting-for-postgresql-12-...
- paulddraper 7y agoThis is the best news I've heard all week.
- munk-a 7y agoI have tried to express my joy at this news to my less SQL literate co-workers... that failed so I wanted to let it out here. This is the best news, I am overjoyed!
- jeltz 7y agoMy favorite feature of PostgreSQL 12 except perhaps REINDEX CONCURRENTLY, but I am very biased since I was involved in both patches (both were large projects involving many devs and reviewers). It is awesome to finally see both land.
- colanderman 7y agoOh wow, that is news to me! A welcome change.
- hans_castorp 7y agoWhich is very often a good thing. I have tuned more than one query by moving a sub-query/derived table into a CTE. What bothers me more, that a CTE prevents parallel execution, but I think that too is fixed with Postgres 12