Hacker News Reader

Comment by vampirechicken | Hacker News Reader

Why would you insist on creating and destroying a db connection on each request? We stopped doing that decades ago.

Django hasn't stopped insisting on that... v1.5 might have pooling, but it's taken them a long time to get connection pooling in.

Forgive my ignorance, but isn't this the point of something like pgpool? I didn't think connecting to a connection pool would be as expensive as connecting to the database itself (if it is, then my next question would be: What's the point of a connection pool? Because clearly I've missed something one way or the other).

Yes, but pgpool isn't always an option. If you use Heroku's Postgres service, you do not have sufficient privileges to run the commands to attach to software like pgpool.

The only way we were able to get connection pooling working in django 1.3/1.4 was to use django-dbpool[0]. It works okay, but is still pretty sketchy compared to the connection pooling libraries available for the JVM like BoneCP or C3P0.

[0] https://github.com/gmcguire/django-db-pool

You can still us pg_pool with heroku.

Understood, thank you for the clarification.

Yes, connecting repeatedly to pgpool is less expensive than doing it directly to postgres. Not having to connect repeatedly to anything is even better.

Wow. I'd just have assumed that connection pooling was default in all these modern web frameworks. I guess this is one area where Enterprise means you get what you pay for? Example: ODBC connection pooling with ASP pages back in the late '90s.

Connection pooling in postgres can actually be counter productive with high concurrency. Postgres scales very badly to high number of connections.

Reply on news.ycombinator.com