seems like `cargo nextest run` just runs `--lib` tests by default? however, `cargo test` is not so slow if you do `cargo test --lib`. how do I get nextest to execute the doc tests, too?
I feel like the less tolerance I have for ads (as time goes on), the more desperate they get in trying increasingly aggressive ways of making you watch ads. I'm never watching ads again, ever! I'm willing to pay, but not with my time for your terrible, horrendous, bullshit ads!
I don't know, man, glossy magazine ads were glamorous. sure there was stupid stuff, but the comparison between the "one weird trick" era and magazine ads of someone looking cool so you have a positive impression with some brand name is pretty stark.
redis is single-threaded but handles lots of connections (i.e. > 500) with much better performance vs. postgres. there's zero chance someone building postgres in 2025 would do one process per connection, I don't think there's any argument that it's a good design for performance. it's just a long-ago design choice that would be difficult to change now.
> The real bottleneck is the single-threaded main loop in the postmaster.
A single-threaded event loop can do a lot of stuff. Certainly handle 4000 tasks of some sort in under 10s. Just offhand it seems like it would be eminently possible to handle incoming connections on the scale they describe in a single-threaded event loop.
Clearly the existing postgres postmaster thread is a bottleneck as it is implemented today. But I'd be interested to go deeper into what it's doing that causes it to be unable to keep up with a fairly low workload vs. what is possible to do on a single thread/core.
ripgrep is one of the main reasons I got interested in rust. it worked so well, it piqued my interest that it was written in rust. many years later, very glad about that. been using `rg` daily since then as well!