Message-ID: <3F72F85A.5040600@persistent.co.in>
Date: Thu, 25 Sep 2003 19:44:50 +0530
From: Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Organization: Persistent Systems Pvt. Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.5b) Gecko/20030917 Thunderbird/0.3a
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Treat <xzilla@users.sourceforge.net>,
	Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [pgsql-www] NuSphere and PostgreSQL for windows
References: <200309241711.h8OHBMi20283@candle.pha.pa.us>
	<1064492591.25702.2084.camel@camel> <1794.1064494772@sss.pgh.pa.us>
	<3F72F0CF.8050108@persistent.co.in> <2683.1064498510@sss.pgh.pa.us>
In-Reply-To: <2683.1064498510@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> 
>>Considering this could be a configure time option, you mean to say
>>that even on Unix we could get threaded postgresql which would not
>>require any shared buffers but instead operate upon local shared
>>buffers only?
> 
> 
> Only if we were prepared to support multiple, no doubt incompatible
> threading libraries, which is exactly what I wasn't volunteering us for.

In my view, we have a advantage here. If we say that we would support a 
reasonable pthreads implementation, that would be good enough, because we have a 
working product in process model.

So we can let that platform catchup with threading model at it's own pace.  Till 
that time it can work in older model. We need not push really hard for platform 
incompatible threading models like say mysql have to do.

The little pthreads programming I did on linux/freeBSD tells me that it supports 
majority of features except TLS(linux2.4/linuxthreads) and per thread signals. 
IIRC HP-UX supports pthreads as well and recommends moving to that threading 
model. Solaris surely does support pthreads.

>>I am sure local buffers would be lot cheaper than shared buffers.
> On what do you base that?  It sounds like pure fantasy to me.  RAM is RAM.

For sure that is correct. But kernel interaction would matter. e.g. a linux 
kernel without pre-emption/low latency and one with all those features would 
certainly register speed and latency differences for heavily contended buffers. 
The issue will be even more grave for small amount of buffers since they will be 
contended more.

Its not about RAM. Its about how lightweight and/or efficient kernel 
implementaion of shared memory and cross-process synchronisation object is. 
Surely say linux and solaris are going to register differences..:-)

  Shridhar