‹ BackHN Continuity

Thread

Training a 4B model to produce 81% faster query plans than Postgres

702 points · 144 comments · polyphilz

  1. 2001zhaozhao · · focus · HN ↗
    Engineer: "HELP, our production DB is frozen on this query that worked fine before!"

    Infra: "Hmm, let's check... Well would you look at that, it seems like your LLM query planner usually works and produces fast queries, but this time when you changed a variable name to trigger query rebuild, it happened to hallucinate and miss an index, would you mind re-running the LLM a few times until you get a faster query?"

    1. malisper · · focus · HN ↗
      Funnily enough, you could replace "LLM query planner" with just "query planner" and this comment would still hold true
      1. Tanjreeve · · focus · HN ↗
        That bug is fixable and verifiable. The LLM you cross your fingers till the next time the same thing happens.
        1. d0100 · · focus · HN ↗
          I've reduced queries from minutes long to 2s in Postgres by duplicating a CTE and keeping it unused

          Query planner feels pretty LLM-esque already

          1. Tanjreeve · · focus · HN ↗
            This isn't a conversation about the guts of query planners but postgres is known for what can only be described as gremlins in the query planner. But that is not the same thing as being non deterministic.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.