‹ BackHN Continuity

Thread

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

702 points · 144 comments · polyphilz

  1. foota · · focus · HN ↗
    Funny enough I was thinking about something very similar to this based on the Jev model posted yesterday.
    1. jwpapi · · focus · HN ↗
      I’ve played with it already. I don’t think this is the use case. I think Jev’s use case is fast, cheap and somewhat easy classification. It’s not trainable in the way you would want here. Even though it’s fast it wont be faster than pgs query optimizer.

      At least as I understand things.

      How did you plan to use Jev for query optimization?

      1. orliesaurus · · focus · HN ↗
        I am still struggling to understand a use-case for Jev. Isn't what was explained in this article a classification problem? I.e. find and aggregate data?
        1. odo1242 · · focus · HN ↗
          The number of options has to be small and bounded. The query planning is more of a search/optimization problem than a classification problem since the number of options increases wildly based on query size.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.