On 11/22/10 18:47, Kevin Grittner wrote:
Ivan Voras<ivoras@xxxxxxxxxxx> wrote:
It looks like a hack
Not to everyone. In the referenced section, Hellerstein,
Stonebraker and Hamilton say:
"any good multi-user system has an admission control policy"
In the case of PostgreSQL I understand the counter-argument,
although I'm inclined to think that it's prudent for a product to
limit resource usage to a level at which it can still function well,
even if there's an external solution which can also work, should
people use it correctly. It seems likely that a mature admission
control policy could do a better job of managing some resources than
an external product could.
I didn't think it would be that useful but yesterday I did some
(unrelated) testing with MySQL and it looks like its configuration
parameter "thread_concurrency" does something to that effect.
Initially I thought it is equivalent to PostgreSQL's max_connections but
no, connections can grow (MySQL spawns a thread per connection by
default) but the actual concurrency is limited in some way by this
parameter.
The comment for the parameter says "# Try number of CPU's*2 for
thread_concurrency" but obviously it would depend a lot on the
real-world load.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
