[dead]
Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
41–50 of 167 posts
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#42Earlier quoted context omitted.
Are you suggesting the AI just rewrites the whole thing under a different license? There’s no way that’s not more dicey than the AGPL license.
That's exactly what they did here, I don't see the difference.
They did it on permissively licensed code would be the difference.
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#43Author here. Let me know if you have any questions about the post or about pgrust. Let me take a shot at answering what I think will be the most common question: how can I trust pgrust? Our #1 priority right now is correctness. Over the past two weeks, I've done a mix of formal verification and differential fuzz testing. We've been able to prove over 1000 user facing functions have the exact same logic in both pgrust…
This is a great project. Thank you! A question on 20s postgresql time - It does not look like you are accounting for reading data from disk? Wouldn't the aggregation query have to load data from disk first? Or is it somewhat guaranteed that the table is already in memory? The Rust version is clearly in memory (I am no rust expert, so that may not even be actually in memory, if its a generator).
> A question on 20s postgresql time - It does not look like you are accounting for reading data from disk
I choose the data size so that it would fit in memory on the machine I was testing on. fwiw, there's still a ton of overhead Postgres has that the toy example does not. For example Postgres will serialize the numbers into tuples and need to deserialize them to execute the query. That's why it's not an apples-to-apples comparison
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#44Earlier quoted context omitted.
Author here. At least for databases, AGPL (or stricter) has become standard. The issue is it's so easy for megacorps (Amazon, Google, etc) to take a permissively licensed product and monetize it at the expense of the original standard. For instance, Mongo, Cockroach, and Materialize have all gone source available. We picked AGPL because it's the best balance between open source and prevents Amazon from just repackagi…
There is nothing wrong with wanting to be compensated for your work, but for people like myself which use a cloud managed DB solution (GCP CloudSQL PostgreSQL) it means something like this would never be available. I consider AGPL a poison pill in my work. That is not true with a suitable commercial license, although I expect a lot more commercial product (support/features/etc). As you note, your objective is to prev…
>we would be happy to dual-license under a commercial license
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#45pgrust seems to have good momentum. AGPL is an odd license for a non web project. Postgres is MIT-like, and that drove it's adoption. Have pgrust folks reconsidered this? Else, IMO we can have an independant rust port of pgrust, which can be MIT, which will garner more attention.
Oh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water. It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such…
AGPL seems like the right choice to me. I’m tired of companies like PlanetScale taking PostgreSQL, building a business on top of it, and then acting like PostgreSQL is theirs to control.
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#46Earlier quoted context omitted.
Are you suggesting the AI just rewrites the whole thing under a different license? There’s no way that’s not more dicey than the AGPL license.
That's exactly what they did here, I don't see the difference.
This is the difference. This guy took an existing source base, had Claude find specific bugs, then had Claude fix a specific bug which was then reviewed by a person. We also don't know if these changes introduce new problems yet. You are suggesting letting Claude write an entirely new source base. That's light-years away from what happened here.
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#47You have no idea how long I have been waiting for adaptive planning. One of my biggest annoyances with the Postgres core team has been their reluctance to implement any sort of adaptive planning despite it, at this point, being a well-established technique that has been implemented in multiple production databases. I hope this, at the very least, proves the viability of this model outside of academic/niche contexts.
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#48Earlier quoted context omitted.
main indeed has two commits, but it clearly states the location of the rest of the commits, so I wouldn't be critical of main itself. hey claude, do a breakthrough You can find the actual git history at the v0.2 github tag. Co-Authored-By: Fable Now we see https://github.com/malisper/pgrust/tree/v0.2 has almost 6000 commits in it, with the very first one on 2026-07-02. That's a lot of token momentum! It's easy to cla…
What's the reason for it? Does not make a lot of sense to keep all the commits elsewhere
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"
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#49Earlier quoted context omitted.
Oh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water. It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such…
If it is indeed 300* faster, I'm sure more rational corporations will rethink their license policy or be left in the dust.
So, keyword 'rational', I'm not sure any sufficiently large company is a rational actor.
Yes, at [tech corp dayjob], any dependency is likely to be banned for arbitrary reasons if you bring it to the attention of the wrong people. It doesn't have to go against any of our policies e.g. don't mention anything with GPL in the name around the "risk" people. In fact, do not ever talk to the "risk" people and hope they don't talk to you.
Latest news: Apparently, devtools are a legal risk. Basic reverse-engineering of client-side JS is now banned.
The delusions really seem to scale with headcount.
Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
#50Earlier quoted context omitted.
Oh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water. It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such…
AGPL seems like the right choice to me. I’m tired of companies like PlanetScale taking PostgreSQL, building a business on top of it, and then acting like PostgreSQL is theirs to control.
we have not once claimed postgres is under our control. i don't think you understand how open source works but thats ok.