[flagged]
Training a 4B model to produce 81% faster query plans than Postgres
41–50 of 118 posts
Re: Training a 4B model to produce 81% faster query plans than Postgres
#42Funny enough I was thinking about something very similar to this based on the Jev model posted yesterday.
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?
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?
Re: Training a 4B model to produce 81% faster query plans than Postgres
#43> I paid ~$800 to rent a 2x H100 SXM node from Lambda for ~95 hours, and ~$400 in OpenAI API fees to generate the Astra trajectory demonstrations. > a tiny 4B model went from not being able to understand the harness it was wrapped in, to achieving a 1.81x geometric mean speedup and a summed latency decrease of 44.7% across a workload of join-heavy SQL queries I can’t find it in the article (may have skimmed it too mu…
I think the idea would be making a frontier model that does this. One that is trained on multiple queries
Re: Training a 4B model to produce 81% faster query plans than Postgres
#44> Frontier intelligence is extremely powerful; the distillation I did off Astra trajectories is proof enough that large models are not going anywhere Wouldn't admitting this invite trouble due to accusations of distillation flying around between closed and open models.
Yeah don't steal my stolen stuff.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#45Optimal 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.
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.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#46Optimal 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.
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.
The immediate problem: How do you know which one is better without running them?
Re: Training a 4B model to produce 81% faster query plans than Postgres
#47Earlier quoted context omitted.
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.
The immediate problem: How do you know which one is better without running them?
[flagged]
Re: Training a 4B model to produce 81% faster query plans than Postgres
#48Re: Training a 4B model to produce 81% faster query plans than Postgres
#49Re: Training a 4B model to produce 81% faster query plans than Postgres
#50Earlier quoted context omitted.
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?
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?
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.