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

Re: Multi-threading friendliness

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Craig James <craig_james(at)emolecules(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Multi-threading friendliness
Date: 2007-12-17 21:05:41
Message-ID: 4766E4A5.40405@mansionfamily.plus.com (view raw or flat)
Thread:
Lists: pgsql-performance
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


In response to

pgsql-performance by date

Next:From: Robert BernabeDate: 2007-12-18 04:31:44
Subject: Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
Previous:From: Craig JamesDate: 2007-12-17 19:35:18
Subject: Multi-threading friendliness (was: libgcc double-free, backend won't die)

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