To: Grzegorz =?utf-8?Q?Ja=C5=9Bkiewicz?= <gryzman@gmail.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance\@postgresql.org" <pgsql-performance@postgresql.org>,
	Scott Carey <scott@richrelevance.com>, "Jignesh K. Shah" <J.K.Shah@sun.com>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <2f4958ff0903120831q4ca3d0a8o8f2571f16b316ecf@mail.gmail.com>
	("Grzegorz =?utf-8?Q?Ja=C5=9Bkiewicz=22's?= message of "Thu\,
	12 Mar 2009 15\:31\:28 +0000")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <49B7F470.EE98.0025.0@wicourts.gov>
	<C5DDBB25.3333%scott@richrelevance.com>
	<49B8E044.EE98.0025.0@wicourts.gov>
	<2f4958ff0903120831q4ca3d0a8o8f2571f16b316ecf@mail.gmail.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Thu, 12 Mar 2009 17:09:49 +0000
Message-ID: <87k56u652a.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Grzegorz Ja=C5=9Bkiewicz <gryzman@gmail.com> writes:

> So please, don't say that this doesn't make sense because he tested it
> against ram disc. That was precisely the point of exercise.

What people are tip-toeing around saying, which I'll just say right out in =
the
most provocative way, is that Jignesh has simply *misconfigured* the system.
He's contrived to artificially create a lot of unnecessary contention.
Optimizing the system to reduce the cost of that artificial contention at t=
he
expense of a properly configured system would be a bad idea.

It's misconfigured because there are more runnable threads than there are
cpus. A lot more. 15 times as many as necessary. If users couldn't run
connection poolers on their own the right approach for us to address this
contention would be to build one into Postgres, not to re-engineer the
internals around the misuse.

Ram-resident use cases are entirely valid and worth testing, but in those u=
se
cases you would want to have about as many processes as you have processes.

The use case where having larger number of connections than processors makes
sense is when they're blocked on disk i/o (or network i/o or whatever else
other than cpu).

And having it be configurable doesn't mean that it has no cost. Having a te=
st
of a user-settable dynamic variable in the middle of a low-level routine co=
uld
very well have some cost. Just the extra code would have some cost in reduc=
ed
cache efficiency. It could be that loop prediction and so on save us but th=
at
remains to be proven.

And as always the question would be whether the code designed for this
misconfigured setup is worth the maintenance effort if it's not helping
properly configured setups. Consider for example any work with dtrace to
optimize locks under properly configured setups would lead us to make chang=
es
which would have to be tested twice, once with and once without this option.
What do we do if dtrace says some unrelated change helps systems with this
option disabled but hurts systems with it enabled?


--=20
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's RemoteDBA services!