Re: Anyone working on better transaction locking? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Anyone working on better transaction locking?
Date
Msg-id 28028.1050248758@sss.pgh.pa.us
Whole thread Raw
In response to Re: Anyone working on better transaction locking?  (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>)
Responses Re: Anyone working on better transaction locking?  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
[ Warning, topic drift ahead ]

Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> However this would not work in all cases unless you are able to partition the
> data. Otherwise you need a database that can have single database image 
> across machines. 

> If and when postgresql moves to mmap based model, postgresql running on mosix
> should be able to do it.

In a thread that's been criticizing handwavy arguments for fundamental
redesigns offering dubious performance improvements, you should know
better than to say such a thing ;-)

I don't believe that such a design would work at all, much less have
any confidence that it would give acceptable performance.  Would mosix
shared memory support TAS mutexes?   I don't see how it could, really.
That leaves you needing to come up with some other low-level lock
mechanism and get it to have adequate performance across CPUs.  Even
after you've got the locking to work, what would performance be like?
Postgres is built on the assumption of cheap access to shared data
structures (lock manager, buffer manager, etc) and I don't think this'll
qualify as cheap.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Anyone working on better transaction locking?
Next
From: "J M Sykes"
Date:
Subject: Conformance of PostgreSQL to ANSI/ISO Standard