4 ms·
One of the big differences that RethinkDB has going for it is that its connections are based on coroutines, so it's really efficient to have thousands of open c
by habitue 10y ago
One of the big differences that RethinkDB has going for it is that its connections are based on coroutines, so it's really efficient to have thousands of open connections. Postgres uses one process per connection, so it's much harder to scale.
- kod 10y agopgbouncer
- orthecreedence 10y agoHow do you pgbounce a bunch of poller connections? pgbouncer has an event-based acceptor on the front, and a connection pool on the back. If all the connections in the pool are taken, then it will queue up the incoming connections until a backend connection is available. If all backend connections are long-polling, then incoming connections will just hang.
- kod 10y agoIf all the connections in the pool are taken, then the database wouldn't have been getting meaningful additional work done anyway, regardless of your scheme for accepting connections. Having 100-1000x more active connections than you have cores on the box is worse than useless, it's actively detrimental.
- habitue 10y agoExcept it works just fine for RethinkDB because it was designed from the ground up to efficiently send changes from the shards directly to open connections. It's a design tradeoff postgres didn't make and they get other benefits rethinkdb doesn't have. But for this use case RethinkDB has a distinct architectural efficiency advantage