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.
> 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.
Much of the time in a transaction can reasonably be non-db-cpu time, be it io wait or be it client CPU processing between queries.
Note I'm not talking about transactions that run >10 seconds, just ones with the queries themselves technically quite cheap.
At 10% db-CPU-usage, you get a 1 second transaction from just 100ms of CPU.
That many long-running transactions seem like a pretty unusual workload to me and potentially running into isolation issues. I can see running a few of these, but not a lot, especially at the same time?
A few (single digits, maybe low double digits) per database CPU core isn't necessarily too much, of course the pattern can be conflict-heavy, where it would be problematic, but this is not about absolute concurrency but about concurrency needed to saturate CPU.
In a properly optimized database absolute majority of queries will hit indices and most data will be in memory cache, so majority of transactions will be CPU or RAM bound. So increasing number of concurrent transactions will reduce throughput. There will be few transactions waiting for I/O, but if majority of transactions are waiting for I/O, it's either horrifically inefficient database or very non-standard usage.
Your arguments make sense for concurrent queries (though high-latency storage like S3 is becoming increasingly popular, especially for analytic loads).
But transactions aren't processing queries all the time. Often the application will do processing between sending queries to the database. During that time a transaction is open, but doesn't do any work on the database server.
It is bad application architecture. Database work should be concentrated in minimal transactional units and connection should be released between these units. All data should be prepared before unit start and additional processing should take place after transaction ended. Using long transactions will cause locks, even deadlocks and generally should be avoided. That's my experience at least. Sometimes business transaction should be split into several database transaction.
I'm talking about relatively short running transactions (one call to the HTTP API) which load data, process it in the application, and commit the result to the database. Even for those a significant portion of the time can be spent in the application, or communication latency between db and application. Splitting those into two shorter transactions might sometimes improve performance a bit, but usually isn't worth the complexity (especially since that means the database doesn't ensure that the business transaction is serializable as a whole).
For long running operations, I usually create a long running read-only transaction/query with snapshot consistency (so the db doesn't need to track what it reads), combined with one or more short writing transactions.
If you aren't hitting IO (I don't mean HDDs) on a large fraction of queries you either skipped a cache in front of the DB or your data is very small or you spent too much on RAM and too little on your NVMe being not a bottleneck.
A process that is blocked for io, whether network or disk, will get taken off the cpu and another process put on the cpu. It doesn’t just waste the cpu until the quanta is gone.
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.
It's about queueing work, not running all these queries at the same time. You can run pgbouncer or you can have a pool on your backend. Having more connections won't make it go faster, so that really seems like a low-priority thing for postgres to me. Even if you integrated pooling into postgres the overhead of auth would be still taking time for small queries anyway.
Honestly, where do people live that the DMV (or equivalent - in some states it is split or otherwise named) is a pain? Every time I've ever been it has been "show up, take a number, wait 5 minutes, get served" - and that's assuming website self-service doesn't suffice.
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!
I haven’t used qbasic in years, but hacking on nibbles is why I learnt qbasic, and I’d say that experience is a decent early chunk of why I’m an AI professor now. Nothing wrong with playing with languages that feature software you love!
imagine some people started using hammers as weapons, leading to some gruesome murders vividly depicted by the news. as a result, construction companies started advertising that this house was built without the use of ANY hammers. that's how I feel about cookies.
cookies are not the problem. spyware is the problem. the way cookies work is, the server includes a "SET-COOKIE" header in its response. it is literally a request, which has no power, other than your computer deciding to store the data locally and include the cookie as a header in its subsequent requests.
somehow instead of us collectively relying on our own user agents to not comply with requests from remote servers that are not in our interest, we settled on deciding the cookie itself is a dangerous mechanism, which is stupid.
reply