[jacobian]

Not exactly. It's not proper connection pooling -- for that, you still should be using an external pool like pgbouncer. Instead this is a single persistent connection per thread. The speed improvement should be about the same, but you something like pgbouncer gives you more control over the number of connections and offers a ton of extra features.

[foobarram]

Thank you very much for the clarification `jacobian` - I am assuming that django's connection pooling on 1.6 would still play nice with pgBouncer.

[jacobian]

Mmmm.... I mean, it would, I guess, but I wouldn't recommend using both unless you can show a marked speed improvement over just using pgbouncer. A real connection is (probably) better than persistent connections, so you probably only need the one.

Now, I've not benchmarked this, so it's just a guess. Further, the specific performance characteristics will depend on your specific setup -- particularly upon where you have pgbouncer running -- so the only real answer is to benchmark and see.

New Relic does a good job showing time spent connecting to the db, fwiw, so you may want to give that a try.

[foobarram]

Thanks again for your answer - I have noted this down now. I will benchmark both cases (CONN_MAX_AGE and PgBouncer) and see which one is faster. Would like to thank you (!!) for the awesome python framework - Django.