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