Good CTE, Bad CTE

(boringsql.com)

46 points | by radimm 1 day ago

6 comments

  • vlaaad 3 hours ago
    Use the term, never define the term, classic.

    CTE stands for Common Table Expressions in SQL. They are temporary result sets defined within a single query using the WITH clause, acting like named subqueries to improve readability and structure.

    • radimm 3 hours ago
      OP here, damn - that's a very good point. Can't believe I missed it.
      • iainmerrick 2 hours ago
        From the headline, I thought it might be about sports-related concussions!

        I was morbidly curious what a "good CTE" could possibly be...

        • QuantumNomad_ 50 minutes ago
          As someone who is not much of a sports person, now I was wondering what CTE means in sports.

          Seems to be this:

          > Chronic traumatic encephalopathy (CTE) is a progressive neurodegenerative disease […]

          > Evidence indicates that repetitive concussive and subconcussive blows to the head cause CTE. In particular, it is associated with contact sports such as boxing, American football, Australian rules football, wrestling, mixed martial arts, ice hockey, rugby, and association football.

          https://en.wikipedia.org/wiki/Chronic_traumatic_encephalopat...

          • iainmerrick 1 minute ago
            Yeah - Muhammad Ali is the most famous victim (or at least likely victim, I don’t think he was officially diagnosed with CTE as it wasn’t well understood back then). In the UK, it’s gradually becoming recognised as a serious problem in rugby.
    • tclancy 37 minutes ago
      Agreed. I was relieved to see this wasn’t written by Cam Skatteboro.
  • yen223 2 hours ago
    I've always thought of CTEs as a code organisation tool, not an optimisation tool. The fact the some rdbms treats them as an optimisation fence was a bug, not a feature.
    • solumunus 2 hours ago
      Improved readability is definitely the primary benefit.
  • uwemaurer 1 hour ago
    Great article, I always like to structure my queries with CTEs and I was (wrongly) assuming it all gets inlined at the end. Sometimes it also gets complicated since these intermediate results can't be easily seen in a SQL editor. I was working on a UI to parse CTE queries and then execute them step by step to show the results of all the CTEs for easier understanding of the query (as part of this project https://github.com/sqg-dev/sqg/)
    • siddboots 50 minutes ago
      I think your assumption about inlining is essentially correct. As far as I know postgres was the last major rdbms to have an optimiser fence around CTEs.
  • dspillett 2 hours ago
    I wrangle databases by day, and do martial arts of an evening. Two arenas where CTEs can cause significant headaches!
  • bob1029 2 hours ago
    > Recursive CTEs use an iterative working-table mechanism. Despite the name, they aren't truly recursive. PostgreSQL doesn't "call itself" by creating a nested stack of unfinished queries.

    If you want something that is more like actual recursion (I.e., depth-first), Oracle has CONNECT BY which does not require the same kind of tracking. It also comes with extra features to help with cycle detection, stack depth reflection, etc.

    If your problem is aligned with the DFS model, the oracle technique can run circles around recursive CTEs. Anything with a deep hierarchy and early termination conditions is a compelling candidate.

  • qwertydog 2 hours ago
    Great post - thanks. I think the columns in the index you suggested in the pre-pg12 section are in the wrong order (that index would get used)
    • radimm 2 hours ago
      Thanks - I will recheck later today.