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
I disagree. If that was the case, pgBouncer wouldn't need to exist.

The problem of resource usage for many connections is real.

>>hu3+Pk3
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.

>>IsTom+Hs3
that's too simplistic.

there are many reasons to need something like pgbouncer.

1) not all workloads lend themselves to backend pools

2) not all backends can afford pooling

3) you don't always control your backend

4) you might have a lot of different backends connecting to the database. it's much simpler to just tell them to connect to pgbouncer.

5) you don't want to trust backend team to not bring postgresql down with many simultaneolus connections.

6) backend pools often misbehave

people don't wake up one day and just add another cog to their infrastructure randomly.