Skip site navigation (1) Skip section navigation (2)

Re: Performance under contention

From: Ivan Voras <ivoras(at)freebsd(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance under contention
Date: 2010-11-25 12:39:42
Message-ID: iclle6$jdq$1@dough.gmane.org (view raw or flat)
Thread:
Lists: pgsql-performance
On 11/22/10 18:47, Kevin Grittner wrote:
> Ivan Voras<ivoras(at)freebsd(dot)org>  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.



In response to

pgsql-performance by date

Next:From: Divakar SinghDate: 2010-11-25 14:53:40
Subject: Re: Which gives good performance? separate database vs separate schema
Previous:From: tvDate: 2010-11-25 12:25:33
Subject: Re: Which gives good performance? separate database vs separate schema

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group