51–54 of 54 posts
Earlier quoted context omitted.
It's multithreaded PgBouncer.
pgbouncer is event based for a reason, they recently added an option to run multiple processes listening on the same socket so that allows it to utilize all available cores.
Earlier quoted context omitted.
Starting from version 1.12.0 you can actually run multiple pgbouncer processes listening on the same port, that eliminates some of the issues.
Yes, we use a cascade of PgBouncers. But it's hard to maintain, actually. Also, PgBouncer was not actively developed for years. I consider new PgBouncer features (port reuse, SCRAM-SHA-256) accomplishment of Odyssey to some (small) extent :)
They had releases at least once a year (only in 2018 they had one release).
Earlier quoted context omitted.
Yes, we use a cascade of PgBouncers. But it's hard to maintain, actually. Also, PgBouncer was not actively developed for years. I consider new PgBouncer features (port reuse, SCRAM-SHA-256) accomplishment of Odyssey to some (small) extent :)
Not sure what you mean that it wasn't developed for years. They had releases at least once a year (only in 2018 they had one release).
Earlier quoted context omitted.
> Having said that pooler is needed in all databases not just PostgreSQL. An evidence for it is just recently released MySQL proxy service in AWS. That's a bit apples and oranges though. The main use-case for that AWS MySQL proxy is high-concurrency Lambda/serverless applications, which conceptually have no other possible means of persistent connections or application-side connection pooling. MySQL's thread-per-conn…
PostgreSQL also can also handle thousands of connections (if you have enough RAM) the problem is that it won't be as performant, due to how concurrency works. You get increased performance until a certain point (typically 2*number of true cores + more if database waits for disk), after that your performance starts degrading due to overhead. That's how time slicing works. Thread-per-conn can make the overhead smaller…
That's the key difference here, combined with the observation that for user-facing web applications, a decent portion of direct DB connections (i.e. without a multiplexing proxy or conn pool) tend to be idle at any given time.
Assuming good configuration of session-level buffer sizes, MySQL can happily have several thousand idle connections at any given time, with no detrimental performance penalty and without requiring a massive amount of RAM. It's been a while since I've examined Postgres under similar conditions, but previously this certainly was not the case there.