But how will you know that the query plan actually does what your query asked for?
you'll have to prove equivalence through some Lean4 code perhaps? or some weird clause tree comparisons... good question indeed.
Training a 4B model to produce 81% faster query plans than Postgres
21–30 of 124 posts
Re: Training a 4B model to produce 81% faster query plans than Postgres
#22> 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.
Frontier model trainers stole almost all the data they've trained on (the whole internet, all copyrighted). It's very hard for them to claim the moral high ground here. It's like stealing an apple from the British Colonial Empire.
Having the moral high ground matters less than having a big warchest of money to spend on lawyers.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#23> 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.
[dead]
Re: Training a 4B model to produce 81% faster query plans than Postgres
#24Funny enough I was thinking about something very similar to this based on the Jev model posted yesterday.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#25Earlier quoted context omitted.
Frontier model trainers stole almost all the data they've trained on (the whole internet, all copyrighted). It's very hard for them to claim the moral high ground here. It's like stealing an apple from the British Colonial Empire.
Having the moral high ground matters less than having a big warchest of money to spend on lawyers.
Does it matter if they companies doing are not in the jurisdiction or even if they are, maybe the can't prove it?
Re: Training a 4B model to produce 81% faster query plans than Postgres
#26> 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.
[deleted]
Re: Training a 4B model to produce 81% faster query plans than Postgres
#27why is this write-up so long? Need 5 days just to go through it.
Think of it like a paper. You wouldn't ask why a paper was so long.
Also you can now ask AI to summarise it for you and even probe with questions pertaining to your specific interests.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#28Earlier quoted context omitted.
I would like to think that pg_hint_plan is designed in such a way that any hint it accepts must be a valid plan for the query. I’m quite confident that schemes with this property that can also express high quality plans are possible and not even excessively complicated. This is not to say that it’s possible to genetically verify that a proposed algorithm does what you want it to — that would be undecidable or NP-hard…
I wouldn't be very excited about adding a 4B param model to my database deployment, but using this kind of approach while testing an app to identify query plans where Postgres is leaving performance on the table seems valuable without much risk.
Given the approach from the article, you can commit the hints to git and run tests for verification. The model would be used during coding.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#29“81% faster query plans than Postgres”…on an 8 GB dataset that fits entirely in memory, with shared_buffers constrained to a fraction of that, queries warmed before measuring, and read-only SELECTs.
I would be cautious about over fitting, it’s tough to say if those query plans would really be more optimal than Postgres heuristics at scale and with a bit more realistic OLTP workloads.
In any case, such is life with profile guided optimization. Many of us appreciate how database workloads can drift over time and with scale.
Kudos to the author for getting their hands dirty and writing up their experiments.
Re: Training a 4B model to produce 81% faster query plans than Postgres
#30why is this write-up so long? Need 5 days just to go through it.
Think of it like a paper. You wouldn't ask why a paper was so long. Also you can now ask AI to summarise it for you and even probe with questions pertaining to your specific interests.
Why wouldn't you ask that? That's exactly why papers have supplementary material