Live data from Hacker News

Good CTE, Bad CTE

boringsql.com

41–47 of 47 posts

Re: Good CTE, Bad CTE

#41

I consulted at some Indian startups. Such bad queries were written which were costing them so much compute I just rewrote all queries with claude code and next day and compute decreased to 1/5th.

Kind of a weird flex - you're basically saying that you aren't any better than the Indian teams at writing efficient queries or optimizing existing ones, the only talent you've demonstrated is ability to ask Claude Code. It's like you are announcing your own obsolescence.

Re: Good CTE, Bad CTE

#42

I consulted at some Indian startups. Such bad queries were written which were costing them so much compute I just rewrote all queries with claude code and next day and compute decreased to 1/5th.

Kind of a weird flex - you're basically saying that you aren't any better than the Indian teams at writing efficient queries or optimizing existing ones, the only talent you've demonstrated is ability to ask Claude Code. It's like you are announcing your own obsolescence.

It's true, claude is already outperforming me

Re: Good CTE, Bad CTE

#43

Earlier quoted context omitted.

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.

I concur, “the Germans” have created an algorithm that completely “see through” subqueries/CTEs when planning a query. The way the query is written has no bearing on the execution.

By the Germans, as you referring to Thomas Neumann's database group at TMU, Munich?

Re: Good CTE, Bad CTE

#44
I mostly use CTEs for organization these days, and in rare cases to express queries which cannot be written without them.

These days I often write queries like this (especially when doing exploratory ad hoc queries, but also in apps) even when it's not necessary to use a CTE:

    WITH
      a AS (
        SELECT ... FROM ... WHERE ... etc.
      )
    SELECT * FROM a
The first CTE query defines the input, and the main query just reads from it. Subsequent subqueries invoke steps on that input to group, filter, join, and so on.

This has a bunch of nice benefits. For example, it allows me to add steps incrementally, and to "comment out" a step I can simply change the next step's input to read from the preceding step. Each step can be read and understood in isolation.

I work a lot with Postgres, ClickHouse, and SQLite, and generally find that the database inlines and optimizes CTEs, and challenges mostly concern performance traps (like IN or EXISTS) that allly to non-CTE situations as well.

Re: Good CTE, Bad CTE

#45

Earlier quoted context omitted.

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, m…

Yep, that's it. The NFL in the US has famously gone to great lengths to downplay the impact of CTE on current and retired players. And there have been several famous players who literally lost their minds as they aged, and we now know that was due to CTE. Something like 90% of ex-NFLers have it. The number is still really bad for collegiate players. And even high school players are at risk. It was to the point that W…

I’ve been playing Madden for years and they literally fazed out concussions in the game in their attempt to downplay the risks.

Re: Good CTE, Bad CTE

#46

Earlier quoted context omitted.

I concur, “the Germans” have created an algorithm that completely “see through” subqueries/CTEs when planning a query. The way the query is written has no bearing on the execution.

By the Germans, as you referring to Thomas Neumann's database group at TMU, Munich?

*TUM (Technical University of Munich).

Re: Good CTE, Bad CTE

#47
post #27

Earlier quoted context omitted.

Your comment could have been more helpful without the first sentence. SAME content, same correction, less superiority: "CTE is an overloaded term, in this article ......" This is a valuable comment, don't ruin it with sarcasm and rudeness.

> Your comment could have been more helpful without the first sentence. no it wouldn't the whole point is to critique the post

You can critique without being sarcastic:

> Use the term, never define the term, classic.

Communicate the same thing in a way you'd do to someone's face:

> This article doesn't define the term "CTE".

Or even more directly, still not rude:

> I wish the article had defined its terms! "CTE" stands for "Common Table Expressions..."

Post reply on HN