Difference between CTE and SubQuery?

Question

From this post How to use ROW_NUMBER in the following procedure?

There are two versions of answers where one uses a sub-query and the other uses a CTE to solve the same problem.

Now then, what is the advantage of using a CTE (Common Table Expression) over a 'sub-query`(thus, more readable what the query is actually doing)

The only advantage of using a CTE over sub-select is that I can actually name the sub-query. Are there any other differences between those two when a CTE is used as a simple (non-recursive) CTE?

Answer 1

In the sub-query vs simple (non-recursive) CTE versions, they are probably very similar. You would have to use the profiler and actual execution plan to spot any differences, and that would be specific to your setup (so we can't tell you the answer in full).

In general; A CTE can be used recursively; a sub-query cannot. This makes them especially well suited to tree structures.

Answer 2

The main advantage of the Common Table Expression (when not using it for recursive queries) is encapsulation, instead of having to declare the sub-query in every place you wish to use it, you are able to define it once, but have multiple references to it.

However, this does not mean that it is executed only once (as per previous iterations of this very answer, thank you to all those that have commented). The query definitely has the potential to be executed multiple times if referenced multiple times; the query optimizer ultimately makes the decision as to how the CTE should be interpreted.

Answer 3

CTE's are most useful for recursion:

WITH hier(cnt) AS (
        SELECT  1
        UNION ALL
        SELECT  cnt + 1
        FROM    hier
        WHERE   cnt < @n
        )
SELECT  cnt
FROM    hier

will return @n rows (up to 101). Useful for calendars, dummy rowsets etc.

They are also more readable (in my opinion).

Apart from this, CTE's and subqueries are identical.

Answer 4

One difference that hasn't been mentioned is a single CTE can be referenced in the several parts of a union

Answer 5

Unless I'm missing something, you can name CTE's and subqueries just as easily.

I guess the main difference is readability (I find the CTE more readable because it defines your subquery up front rather than in the middle).

And if you need to do anything with recursion, you are going to have a bit of trouble doing that with a subquery ;)

Answer 6

One important fact that nobody has mentioned is that (at least in postgres), CTEs are optimization fences:

https://blog.2ndquadrant.com/postgresql-ctes-are-optimization-fences/

That is, they will be treated as their own atomic query, rather than folded into the whole query plan. I lack the expertise to give a better explanation, but you should check the semantics for the version of sql you are using; for advanced users, being able to create an optimization fence can help performance if you are expert level in controlling query planner; in 99% of cases, however, you should avoid trying to tell the query planner what to do, because what you think will be faster is likely worse than what it thinks will be faster. :-)

Answer 7

Adding to others' answers, if you have one and the same subquery used several times, you can replace all these subqueries with one CTE. This allows you to reuse your code better.

Answer 8

One thing that you need to understand also is that in older versions of SQL Server (yes many people still need to support SQL Server 2000 databases), CTEs are not allowed and then the derived table is your best solution.

Answer 9

HINT: (MAXRECURSION n)

you can limit the number of recursion levels allowed for a specific statement by using the MAXRECURSION hint and a value between 0 and 32,767 in the OPTION clause

For example, you could try:

OPTION 
      (MAXRECURSION 150)

GO