-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh Berkus wrote:
| Gaetano,
|
|
|>Of course your are speaking about the "worst case", I aplly in scenarios
|
| like
|
|>this on the rule 80/20: 80% of connection will perform a sort and 20% will
|
| allocate
|
|>memory for the sort operation in the same window time:
|
|
| Well, I suppose it depends on how aggresive your connection pooling is. If
| you minimize idle connections, then 300 connections can mean 200 concurrent
| queries. And since Paul *is* having problems, this is worth looking into.
With 4 CPU ( like Paul have ) there is a lot of space in order to have 200
concurrent connection running but I don't believe that all 200 togheter are
allocating space for sort, I have not seen the code but I'm quite confident
that the memory for sort is released as soon the sort operation is over,
not at the end of connection.
Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBFBcn7UpzwH2SGd4RAuNhAJ0f+NVUlRUszX+gUE6EfYiFYQy5JQCgnaRj
HcguR1U3CgvQiZ4a56PBtVU=
=6Jzo
-----END PGP SIGNATURE-----
