Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 7ADD62E0171
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Sun, 16 Dec 2007 18:22:00 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 55637-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Sun, 16 Dec 2007 18:21:57 -0400 (AST)
Received: from pih-relay08.plus.net (pih-relay08.plus.net [212.159.14.134])
	by postgresql.org (Postfix) with ESMTP id 2E16A2E0170
	for <pgsql-performance@postgresql.org>;
	Sun, 16 Dec 2007 18:21:57 -0400 (AST)
Received: from [80.229.150.39] (helo=mansionfamily.plus.com)
	by pih-relay08.plus.net with esmtp (Exim) id 1J41rv-0005Mb-7a
	for pgsql-performance@postgresql.org; Sun, 16 Dec 2007 22:21:55 +0000
Received: from [192.168.0.87] ([192.168.0.87]:1640)
	by mansionfamily.plus.com with [XMail 1.22 ESMTP Server]
	id <SD3BE> for <pgsql-performance@postgresql.org> from
	<james@mansionfamily.plus.com>; Sun, 16 Dec 2007 22:27:16 -0000
Message-ID: <4765A581.7040801@mansionfamily.plus.com>
Date: Sun, 16 Dec 2007 22:24:01 +0000
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Gregory Stark <stark@enterprisedb.com>,
	Magnus Hagander <magnus@hagander.net>,
	Craig James <craig_james@emolecules.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-performance@postgresql.org
Subject: Re: libgcc double-free, backend won't die
References: <4729B1E9.2080306@gmail.com> <475E4133.5080009@emolecules.com>
	<20071211112128.GB4708@alvh.no-ip.org>
	<475EA754.1090307@emolecules.com>
	<20071211151416.GD10710@alvh.no-ip.org>
	<475EA9FD.9000706@emolecules.com>
	<20071211152010.GE10710@alvh.no-ip.org> <475EAB69.9@emolecules.com>
	<20071211152838.GH4708@alvh.no-ip.org>
	<475EB1B9.3000405@emolecules.com>
	<20071211155703.GT31937@svr2.hagander.net>
	<87r6htw4e7.fsf@oxford.xeocode.com>
	<476564D6.7090702@mansionfamily.plus.com>
	<27316.1197828101@sss.pgh.pa.us>
In-Reply-To: <27316.1197828101@sss.pgh.pa.us>
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/252
X-Sequence-Number: 28068

Tom Lane wrote:
> Yes.
>
> 1) It's of no value to us
>
> 2) On many platforms there is a nonzero performance penalty
>
>   
I think you have your head in the ground, but its your perogative.  *You*
might not care, but anyone wanting to use thread-aware libraries (and I'm
*not* talking about threading in any Postgres code) will certainly value 
it if
they can do so with some stability.

There's a clear benefit to being able to use such code.  I suggested a
build option but you reject it out of hand.  And in doing so, you also 
lock out
the benefits that you *could* have as well, in future..  It seems religious,
which is unfortunate.

Are you suggesting that the performance penalty, apart from the
malloc performance (which is easily dealt with) is *material*?
An extra indirection in access to errno will hurt so much?  Non-zero I can
accept, but clinging to 'non-zero' religiously isn't smart, especially 
if its a
build-time choice.

We'll clearly move to multiple cores, and the clock speed enhancements will
slow (at best).  In many cases, the number of available cores will 
exceed the
number of instantaneously active connections.  Don't you want to be able
to use all the horsepower?

Certainly on the sort of systems I work in my day job (big derivative 
trading
systems) its the norm that the cache hit rate on Sybase is well over 
99%, and
such systems are typically CPU bound.  Parallelism matters, and will matter
more and more in future.

So, an ability to start incrementally adding parallel operation of some 
actions
(whether scanning or updating indices or pushing data to the peer) is 
valuable,
as is the ability to use threaded libraries - and the (potential?) 
ability to use
embedded languages and more advanced libraries in Postgres procs is one 
of the
advantages of the system itself.  (I'd like to discount the use of a 
runtime in a
seperate process - the latency is a problem for row triggers and functions)

James