pgrust Faster Than Postgres? | Scaling Postgres 426

Our first piece of content is the four horsemen behind thousands of Postgres outages.

This is from malicebird.me. And of course, this is a click baity title, but these are some of the things he sees and suggests he wants to change or fix in PGRust.

And again, this is a Rust rewrite of Postgres.

So the first thing he addresses is vacuum and transaction ID wrap around.

and transaction id wrap around is a definite concern as your database grows because we're still using 32-bit transaction ids and i can only assume he's going to be using 64-bit and his intent is to change how rollbacks happen and use an undo log like oracle does probably to avoid having to vacuum the heap.

But both of these are goals.

They are not present yet, presumably because he has to get the regression tests passing.

So he's just trying to match Postgres at this point.

These are just future looking things as far as I understand it.

The next is connection limits and query parallelism.

And he's basically knocking the Postgres process model, although he makes some of these statements that I'm like, that doesn't happen, because he says, quote, if more things try to connect to Postgres than the connection limit, they won't be able to, that's true, and your database will go down.

I've never seen a database go down due to too many connections.

The database stops additional people from connecting.

But basically, he's going to be using a thread-based model, and he says this was architected from day one with it.

And he says even though the process model is safer, Rust provides safety guarantees for these threads, so it should be fine.

The next item he calls out is bad query plans.

Now again, with pgplanadvice, this is not as relevant too much anymore.

But again, this is all forward-facing that he wants to do with pgrust, as he wants to build an adaptive query planner.

and that if a query normally takes 10 milliseconds, suddenly takes 10 seconds, PGRust would detect the regression, check if the plans changed, or check if the statistics drifted and make a correction.

Although in theory, you could make this enhancement to Postgres today.

It should be tracking sufficient information to detect plan flips.

I'm not saying it would be easy, but I could see how that feature could be added.

Next, he talks about JSON and the fact it does not collect statistics, and that's something he wants to do.

But again, Postgres could start tracking some sort of statistics for JSON as well.

So this gives you a sense of what he's going for.