Re: SAN, clustering, MPI, Backplane Re: Postgresql on SAN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SAN, clustering, MPI, Backplane Re: Postgresql on SAN
Date
Msg-id 2418.1089431290@sss.pgh.pa.us
Whole thread Raw
In response to SAN, clustering, MPI, Backplane Re: Postgresql on SAN  (Andrew Piskorski <atp@piskorski.com>)
Responses Re: SAN, clustering, MPI, Backplane Re: Postgresql on SAN  (Gaetano Mendola <mendola@bigfoot.com>)
List pgsql-hackers
Andrew Piskorski <atp@piskorski.com> writes:
> Another thing I've been wondering about, but haven't been able to find
> any discussion of:
> Just how closely tied is PostgreSQL to its use of shared memory?

Pretty damn closely.  You would not be happy with the performance of
anything that tried to insert a network communication layer into access
to what we think of as shared memory.

For a datapoint, check the list archives for discussions a few months
ago about performance with multiple Xeons.  We were seeing significant
performance degradation simply because the communications architecture
for multiple Xeon chips on one motherboard is badly designed :-(
The particular issue we were able to document was cache-line swapping
for spinlock variables, but AFAICS the issue would not go away even
if we had a magic zero-overhead locking mechanism: the Xeons would
still suck, because of contention for access to the shared variables
that the spinlocks are protecting.

OpenMosix is in the category of "does not work, and would be unusably
slow if it did work" ... AFAIK any similar design would have the same
problem.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [Plperlng-devel] Re: plperl security
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: [PATCHES] Fixes for pg_dump and ownership/acl problems