Hacker News new | comments | show | ask | jobs | submit login

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.



pgbouncer


How 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.


If 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.


Except 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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: