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

Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

github.com

Post reply on HN
Print view View original

321–330 of 756 posts

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#321

Post by ptrwis »

malisper wrote: post #258
dimes wrote: post #242

Earlier quoted context omitted.

While a thread-per-connection seems like an improvement, do you have any plans to allow query multiplexing over a single connection? That would be a huge improvement IMO.

Can you elaborate on the use case for query multiplexing? Is it so your client would only need to establish one connection with Postgres and then could run as many queries as it wanted?

Not the OP, but yes - just imagine a web server talking to DB over one connection without any connection pooler

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#322

Post by rjh29 »

cyberjar wrote: post #83

I'm starting to get a bit of fatigue for these projects that boil down to just "I asked Claude to re-write this code into a new language that's in vogue right now!" I really don't understand why this is needed outside of an opportunity to show how impressive LLMs can be when working within large codebases, but even then people in the comments are finding bizarre implementation choices that a human developer wouldn't…

In this case it's justified because Rust allows safe implementation of threaded code. Current Postgres is per-process. Switching to threading yields performance improvements.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#323

Post by jeltz »

malisper wrote: post #318
jeltz wrote: post #303

Earlier quoted context omitted.

Threads does not offer any major performance advantage, performance of processes vs threads is virtually the same. The reason the PostgreSQL project is moving towards threads is to make development easier.

> Threads does not offer any major performance advantage This is very not true. When it comes to parallel queries, a process model adds a ton of overhead. You can't pass pointers between processes because the address space is different. This adds a ton of overhead in a bunch of different places. For example when doing a parallel hash join, Postgres will have each worker build a local hash table. Then it will take all…

Ok ... you know PostgreSQL supports hash tables in shared memory, right? PostgreSQL could in theory share those if we wanted to. The issue is just that coding anything which uses shared memory is a lot of work.

Additionally the reasons PostgreSQL does not offer Clickhouse performance has very little to do with parallelism. PostgreSQL plans to move to threading but the efforts around imporving OLAP performance are almost entirely unrelated.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#325

Post by fragmede »

LtWorf wrote: post #301
fragmede wrote: post #93

Earlier quoted context omitted.

Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. T…

Rust doesn't have ACID and I'm sure this doesn't either. I'd like to know if the "authors" know what I'm talking about.

You think that's bad, MongoDB doesn't even have schemas. Schemas!

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#326

Post by teraflop »

otterley wrote: post #304
vintagedave wrote: post #195

This is impressive - but is a license change, from the PostgresQL license [0] to AGPL [1]. I like the AGPL and think it's the best truly free open source license, but I worry if this is compatible. Ie, if this is rewritten from the original source, should the original apply? (Yes.) There has been a trend to rewrite open source software with a more restrictive license (like coretools in Rust). This looks considerably…

If this software was written by a mechanical process, the license is a nullity. It’s public domain.

Being created by a "mechanical process" from an existing creative work doesn't mean it's not a derivative work.

For instance, if I take a copy of $BIG_BUDGET_MOVIE, and resample the video frames from 1080p to 720p through a purely mechanical transformation, that doesn't make the output public domain.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#327

Post by jeltz »

kardianos wrote: post #309
malisper wrote: post #147

Hey author here. Wasn't expecting to see this up. To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture. I'm now working on a new, not yet published version of pgrust that inc…

PG Wire proto 3 is my largest source of frustrations. I'm playing with a POC for a better wire protocol here: https://github.com/solidcoredata/pgwire4

404 Not Found

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#328

Post by maximilianburke »

HeavyStorm wrote: post #191
cyber1 wrote: post #182

2664 "unsafe {", 1835 "unsafe fn". This is completely unsafe. It doesn't look like a rewrite that understands what's actually going on or how the architecture should be redesigned to take advantage of Rust strengths. Instead, it looks like an AI generated transpilation with extensive use of raw pointers.

Why even use rust...

Because in C everything is unsafe, by definition.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#329

Post by pessimizer »

melodyogonna wrote: post #115

Rust and its ecosystem needs to become more original. There are so many new problems that needs software solutions. Existing solutions that already work don't have to be rewritten in Rust.

A lot of it is actually GPL-washing and rust is the excuse.

I'm on the rewrite it in rust bandwagon, but I secretly want to rewrite things in rust so they can be refactored and made easier to maintain and add features. So "rewrite it in rust" is just like "rewriting it in anything that I'm currently enamored with," and doing it with an LLM (defactoring?) would miss the point for me.

rust being safe(r) just makes the rewrite less risky.

Post reply on HN