On Thursday 16 October 2003 11:47 am, Mark Harrison wrote:[color=blue]
> We have the situation where it would be convenient if we
> could support a large number (>1024, possibly in the 2000-3000
> range) of client connections.
>
> What are our options for this?[/color]
I suspect your best bet is some sort of connection pooling. Even if
you got PostgreSQL to compile with that many clients, each client
requires a separate backend process so you would have to make sure
that your OS and hardware wouldn't choke when running that many
processes.
I'd start by looking at SQL Relay. It seems to rate pretty well on
Freshmeat and seems to have ongoing development.
There's also dbBalancer. It's supposed to handle native PostgreSQL
pooling but unfortunately it's still listed as "alpha" and no updates
have been posted in about a year so it may be dead.
If you can add a layer to your app you could try aolserver. It's
high-performance, open-source and supports connection pooling
out-of-the-box but would require communicating from the client side
via http.
There's also the connection pooling available in Java.
All of this pooling talk assumes, of course, that your clients aren't
so active that the pool of "real" connections becomes exhausted.
Just a few places to look. Others may have ideas as well.
Cheers,
Steve
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to
majordomo@postgresql.org)
maximum number of client connections? 
