Really, this seems like it would be a pretty strong case for a
replicated database..... assuming not all 10000 clients will need to be
doing modifications. Or if they do, that they could open up a seperate,
temporary connection with the master db.
On Aug 16, 2004, at 7:37 AM, Peter Eisentraut wrote:
> Am Montag, 16. August 2004 16:20 schrieb Csaba Nagy:
>> Peter is definitely not a newby on this list, so i'm sure he already
>> thought about some kind of pooling if applicable... but then I'm
>> dead-curious what kind of application could possibly rule out
>> connection
>> pooling even if it means so many open connections ? Please give us
>> some
>> light Peter...
>
> There is already a connection pool in front of the real server, but the
> connection pool doesn't help you if you have in fact 10000 concurrent
> requests, it only saves connection start effort. (You could make the
> connection pool server queue the requests, but that is not the point
> of this
> exercise.) I didn't quite consider the RAM question, but the machine
> is
> almost big enough that it wouldn't matter. I'm thinking more in terms
> of the
> practical limits of the internal structures or the (Linux 2.6) kernel.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly