Used judiciously, a macro system in front of your SQL is often a good approach here. You gain the "linguistically common subtable" capabilities of a CTE, the ability to name constants, and the ability to name/parameterize common sub-expressions, even in databases not supporting CTEs. With LSP support being what it is, you can even whip up editor integration for your new language in a day or less. Compared to CTEs (as…
Postgres feature you're not using – CTEs a.k.a. WITH clauses
21–30 of 32 posts
Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#22Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#23I can't talk for Postgres but on MS SQL it's definitely not like a view.
I had a CTE with a filter condition in the where close but got a conversion error in the later use for a value I already filtered out in the CTE.
So it may look like some kind of temporary view definition but the actual code the optimizer generates may behave unexpected.
Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#24>The general idea is that it allows you to create something somewhat equivilant to a view that only exists during that transaction. I can't talk for Postgres but on MS SQL it's definitely not like a view. I had a CTE with a filter condition in the where close but got a conversion error in the later use for a value I already filtered out in the CTE. So it may look like some kind of temporary view definition but the ac…
You're describing predicate pushdown, which can get hung up under certain conditions, like when using window functions or top. If I had to take a shot in the dark, you were dealing with something like that.
Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#25I sure do use them for many years now, my girlfriend now uses them and loves them, my topcoder friend eventually started using them 10 years ago. So, no, we are using them , but y’all know what ? Unless recursive they are really nothing so special…
However, I will argue that an equally great benefit is code readability. That allows you to give good names to pieces of SQL block is like having small functions in normal programming
Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#26>The general idea is that it allows you to create something somewhat equivilant to a view that only exists during that transaction. I can't talk for Postgres but on MS SQL it's definitely not like a view. I had a CTE with a filter condition in the where close but got a conversion error in the later use for a value I already filtered out in the CTE. So it may look like some kind of temporary view definition but the ac…
I'm all but certain that a CTE and an unindexed view are treated identically in the planning phase. You're describing predicate pushdown, which can get hung up under certain conditions, like when using window functions or top. If I had to take a shot in the dark, you were dealing with something like that.
Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#27This was posted 4 days ago but now says 7 hours ago, even the comments from back then now show as 30 minutes old?
Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#28Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#29Re: Postgres feature you're not using – CTEs a.k.a. WITH clauses
#30Earlier quoted context omitted.
Yep, it's a huge improvement for complicated pipelines. One thing to be aware of is "NOT MATERIALIZED". Here's what the docs say: A useful property of WITH queries is that they are normally evaluated only once per execution of the parent query, even if they are referred to more than once by the parent query or sibling WITH queries. Thus, expensive calculations that are needed in multiple places can be placed within a…
Any issues with recursive and NOT MATERIALIZED? Recursive is pretty much the reason to use CTEs for me and NOT MATERIALIZED is essential there in most cases.