Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

malisper.me

Post reply on HN
Print view View original

71–80 of 167 posts

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#71

Post by yieldcrv »

sgt wrote: post #69
yieldcrv wrote: post #59

Earlier quoted context omitted.

Their ai agents will if we keep writing about it Project managers and Human Resources rolling out overengineered projects will outnumber current software engineers 10 to 1

That's a pretty gloomy view

They will be software engineers or the people doing the software work

And different people will be doing product management and HR

all because today’s software engineers don’t want to babysit AI agents and choose antiquated libraries so that their resume said they'd been using a popular framework for a couple years

Nobody else is playing that outdated game, its just a rotation

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#72

Post by JamesSwift »

mey wrote: post #14
malisper wrote: post #10

Earlier 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…

The whole point is to force the cloud providers to go through a contract negotiation for licensing rather than keep the door open for them. Nothing prevents the parent project from specially licensing to individual parties.

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#74

Post by refulgentis »

Whitespace wrote: post #5
ognarb wrote: post #3

Earlier quoted context omitted.

2 commits in the repo both generated by claude. This is AI slop, I wonder where you see good momentum?

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 do we mean by "easy to claim"? It is written by AI. The 6000 commits are by Claude.

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#75

Post by malisper »

refulgentis wrote: post #73
borplk wrote: post #66

I'll take the 300x slower non-vibe-coded pg, thanks!

They disabled Postgres parallelism to benchmark too. Sigh.

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=-...

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#76

Post by refulgentis »

malisper wrote: post #75
refulgentis wrote: post #73

Earlier quoted context omitted.

They disabled Postgres parallelism to benchmark too. Sigh.

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=-...

Who is "we"?

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#77

Post by wiradikusuma »

claytonjy wrote: post #68
wiradikusuma wrote: post #67

I think in addition to making it faster, it would be useful if it could be made "leaner," e.g. can run better on lower-spec hardware than PG.

does one not imply the other? if it can run faster in the same hardware, it should also run as fast on lower spec hardware

If I'm not mistaken ClickHouse's min spec is quite steep.

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#78

Post by malisper »

refulgentis wrote: post #76
malisper wrote: post #75

Earlier quoted context omitted.

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=-...

Who is "we"?

Me and Jason, the two people working on the project

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#79

Post by jjice »

KolmogorovComp wrote: post #51

Thanks to the authors for choosing a license that respect users freedom, on top of being an awesome technical project.

While I do like pgrust's license, I do feel like it's kind of wrong to port in such a direct way and change the license. I guess this isn't a fork, but it kind of is? It looks like according to this post [0], they did a Claude Fable + Opus re-write. I know that legally this is seemingly a valid way to do things and avoid copyright, but it feels wrong to me. I don't even necessarily think that my feelings are correct, but standing on the backs of giants and using an LLM to "reimplement" the code (not a clean room implementation) feels like it's it _shouldn't_ be a valid way to avoid copyright or allow for license changes.

Now, I don't know how MIT -> AGPL re-licensing specifics work, but still.

[0] https://malisper.me/postgres-in-rust-regression-suite/

Re: Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD

#80

Post by sgt »

yieldcrv wrote: post #71
sgt wrote: post #69

Earlier quoted context omitted.

That's a pretty gloomy view

They will be software engineers or the people doing the software work And different people will be doing product management and HR all because today’s software engineers don’t want to babysit AI agents and choose antiquated libraries so that their resume said they'd been using a popular framework for a couple years Nobody else is playing that outdated game, its just a rotation

What are we going to do about this?
Post reply on HN