zlacker

>>davidg+(OP)
Can’t believe they needed this investigation to realize they need a connection pooler. It’s a fundamental component of every large-scale Postgres deployment, especially for serverless environments.

>>paulkr+Nj2
can't believe postgres still uses a process-per-connection model that leads to endless problems like this one.

>>jstron+tl2
You can't process significantly many more queries than you've got CPU cores at the same time anyway.

>>IsTom+wL2
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.

>>namibj+DO2
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.