I have received a question via the Advocacy site and I am not knowledgeable enough to answer. Can you help?
The question is: can PostgreSQL handle between 10'000 and 40'000 simultaneous connections? The persone asking the question has to choose between Oracle and PostgreSQL, and my guess is that they would be relieved if they could go with PostgreSQL.
Do you have any additional advice I could transmit to this person
about handling that many connections. I'm sure any help we can
provide will be an additional selling point.
Actually, this begs the question: are there any "reverse DB" proxy
servers around that people have used? Having a reverse libpq proxy
server would _rock_. Some light weight multi-threaded proxy that
relays active connections to the backend and holds idle connections
more efficiently than PostgreSQL... well... it'd be a life saver in
sooooo many situations. Granted it'd have its short comings
(connections would persist to the backend along transactions, once
committed, the front end would "detatch" from the backend that it was
using), but this is achitecturally similar to what MS and ORA do to
handle gazillions of connections to a database that in reality, can
only handle a few hundred (maybe a thousand or two) active
connections.
There are 1000's of references to postgresql and connection pooling.
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=pooling+postgresql
Maybe somthing there will work.
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
