Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id A01E12E33F0
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 17 Dec 2007 17:03:39 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 58235-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 17 Dec 2007 17:03:23 -0400 (AST)
Received: from pih-relay05.plus.net (pih-relay05.plus.net [212.159.14.132])
	by postgresql.org (Postfix) with ESMTP id D82C02E33CC
	for <pgsql-performance@postgresql.org>;
	Mon, 17 Dec 2007 17:03:35 -0400 (AST)
Received: from [80.229.150.39] (helo=mansionfamily.plus.com)
	by pih-relay05.plus.net with esmtp (Exim) id 1J4N7e-00070g-2g
	for pgsql-performance@postgresql.org; Mon, 17 Dec 2007 21:03:34 +0000
Received: from [192.168.0.87] ([192.168.0.87]:1798)
	by mansionfamily.plus.com with [XMail 1.22 ESMTP Server]
	id <SD4FE> for <pgsql-performance@postgresql.org> from
	<james@mansionfamily.plus.com>; Mon, 17 Dec 2007 21:08:56 -0000
Message-ID: <4766E4A5.40405@mansionfamily.plus.com>
Date: Mon, 17 Dec 2007 21:05:41 +0000
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Craig James <craig_james@emolecules.com>
CC: Bruce Momjian <bruce@momjian.us>,  pgsql-performance@postgresql.org
Subject: Re: Multi-threading friendliness
References: <200712170852.lBH8qGc18697@momjian.us>
	<4766CF76.1010105@emolecules.com>
In-Reply-To: <4766CF76.1010105@emolecules.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200712/261
X-Sequence-Number: 28077

Craig James wrote:
> Don't confuse thread-friendly with a threaded implemetation of 
> Postgres itself.  These are two separate questions.  Thread-friendly 
> involves compile/link options that don't affect the Postgres source 
> code at all.
Indeed.  I'm specifically not suggesting that Postgres should offer an 
API that can be called from
anything except the initial thread of its process - just that library 
subsystems might want to use
threads internally and that should be OK. Or rather, it should be 
possible to build Postgres
so that its OK.  Even if there's a small slowdown, the benefit of 
running the full JVM or CLR
might outweigh that quite easily *in some circumstances*.

I've also hinted that at some stage you might want to thread some parts 
of the implementation,
but I'm not suggesting that would be an early target.  It seems to me 
sensible to make it
straightforward to take baby steps in that direction in future would be 
a reasonable thing to
do.  As would being friendly to dynamically loaded C++ code.  If you 
create the framework,
(and we're talking the barest of scaffolding) then others can work to 
show the cost/benefit.

I fail to see why this would be a controversial engineering approach.

James