malisper

4 ms·

1.
by malisper 9d ago
Even if the query plan was not generated by an llm, you can't verify it will run in an acceptable time. This is one of the biggest unsolved problems in databases
2.
by malisper 9d ago
> That bug is fixable and verifiable A bad query plan is not your typical kind of bug. I would definitely not call it fixable. Query planners are inherently dealing with estimations and approximations. If the query planners estimation is
3.
by malisper 10d ago
Funnily enough, you could replace "LLM query planner" with just "query planner" and this comment would still hold true
4.
by malisper 15d ago
> I watched an interview that Casey Muratori did with Tyler Cloutier (SpacetimeDB founder and spokesperson) [1]. One of the points that Tyler is that, given modern CPU architecture with cache lines, a distributed database needs to fan ou
5.
by malisper 25d ago
Most of the work I've done with pgrust hasn't had issues with Fable. The only time I've had issues is when building a fuzz tester to find bugs
6.
by malisper 1mo ago
Eval would count as JIT compilation though[0] [0] https://www.sbcl.org/manual/#compiler-only-implementation
7.
by malisper 1mo ago
Author here. Let me know if you have any questions about the post or about pgrust.
8.
by malisper 1mo ago
> There's no rarity of JITs, it's just that LLVM (and other frameworks) are often used Except that using LLVM has high latency limitting it's applicability. Postgres just disabled LLVM by default because of this[0]. [0] h
9.
by malisper 1mo ago
> This person doesn't understand how to make efficient code The author is one of the most knowledgeable people about performance there is
10.
JIT Compiling Code in 5μs(malisper.me)
3 points by malisper 1mo ago|0 comments
11.
by malisper 1mo ago
You still get a physical piece of paper that looks like a check; it's just not a valid check.
12.
by malisper 2mo ago
We've fixed the issue on our development branch. We've only been working with the default collation so when you try a different one it causes an issue
13.
by malisper 2mo ago
How so? Window functions work exactly the same way. Postgres processes them one row at a time, and you can batch them the same way as you would with sum. Window functions do make parallel queries more difficult, but that's a different
14.
by malisper 2mo ago
> You’re cosplaying as someone who could build a database. > In reality you yourself could never build Postgres or Redis or any other database. > You’re not skilled enough or knowledgeable enough and you’re not willing to put the t
15.
by malisper 2mo ago
Can you file an issue? We know there are bugs and the work we're doing with formal verification and fuzz testing is to go through all the code and make sure all of it behaves identically to Postgres
16.
by malisper 2mo ago
We don't expose the priorities right now, but we have the priorities decay over time. That way faster queries get prioritized over long running queries. That should achieve the behavior you're looking for.
17.
by malisper 2mo ago
Can you file an issue? Our big focus over the next few weeks is to eliminate these issues and that's why we're our formal verification and fuzz testing work
18.
by malisper 2mo ago
Yes. Email me and Jason at malis@pgrust.com and jason@pgrust.com
19.
by malisper 2mo ago
I'm certain pgrust can find a long term home somewhere
20.
by malisper 2mo ago
Thanks!
21.
by malisper 2mo ago
What do you mean by native TTL? Would that be when rows are automatically deleted if they aren't touched after a certain period of time?
22.
by malisper 2mo ago
^For context, this is Greg Smith, the author of Postgres 9.0 High Performance[0]. That book was my first introduction to Postgres [0] https://www.amazon.com/dp/184951030X
23.
by malisper 2mo ago
> My understanding is that they used c2rust, and then told the LLM/Agents to make the code more idiomatic rust, while also using the PG test suite as a feedback mechanism. This is correct > and thus a fork, and should thus have t
24.
by malisper 2mo ago
It absolutely can be embedded. The bigger enabler is replacing the process-per-connection model with a thread-per-connection model. Projects like pglite[0] had to give up concurrency because of it. We also support compiling to wasm so you c
25.
by malisper 2mo ago
> I am very disappointed to see the direction: It is moving from a "interesting attempt to recreate system software" to "building flashy but useless demo" What makes you say this is a useless demo? I can't count
26.
by malisper 2mo ago
One of the new features we recently built is "test mode". This brings cloning a template db from 100ms down to <10ms making it much better for tests. If you're interested in trying it out, please reach out to me at malis@p
27.
by malisper 2mo ago
Me and Jason, the two people working on the project
28.
by malisper 2mo ago
We disabled parallelism in the blog post for demonstration purposes. The 300x slower refers to the clickbench numbers[0] where parallelism is enabled [0] https://benchmark.clickhouse.com/#system=+liH|pgrs|gQ&type=-...
29.
by malisper 2mo ago
I would probably dig into the reasons for the differences in the benefit on the test machine and in prod I had an issue like this for optimizing pgrust. I had an optimization that showed no impact on my test machine (c8g.4xl) and showed a 2
30.
by malisper 2mo ago
It's a reference to the prompt that found a counterexample to the Dinitz-Garg-Goemans conjecture > "do a breakthrough and find a structured counterexample"

More ›