Thread

1. hamilyon2 · 1789593005 · focus · HN ↗

   Optimal plan construction is math-heavy, algorithm-heavy and vary even by workload. There are options like creating just-in-time indexes, so solution space grows even faster than article presents. Sometimes it is the query planner which is the slow part of total execution time.

   LLM is kind of blunt weapon to use here. I am waiting rather for alphago style neural net heuristic.

   1. yipinwong · 1789595402 · focus · HN ↗

      What if we use a hybrid model of using both query optimizer and LLM? Whichever produces better result, the database can use?

      - a question from someone with lack of DB depth, me.

      1. Sesse__ · 1789595743 · focus · HN ↗

         The immediate problem: How do you know which one is better without running them?

         1. HighlandSpring · 1789597219 · focus · HN ↗

            Could you A/B at random, use that to collect data and eventually feed that back in to prefer A or B depending on the shape of the query?

            1. adrianN · 1789613617 · focus · HN ↗

               Customers love it when their queries sometimes run a lot longer.
            2. Sesse__ · 1789626204 · focus · HN ↗

               There are papers and Postgres projects that attempt this kind of learning-based optimization, with some success. None are in widespread use. (One part, but certainly not the entirety, of the problem is that it's not just A/B, it's an exponential number of options that all could seem close to each other.)
            3. mike_hearn · 1789628737 · focus · HN ↗

               You can and some databases can do this (e.g. Oracle).

Unofficial Hacker News client; not affiliated with Y Combinator.