From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Piskorski <atp(at)piskorski(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Yannick Lecaillez <yl(at)itioweb(dot)com> |
Subject: | Re: SAN, clustering, MPI, Backplane Re: Postgresql on SAN |
Date: | 2004-07-10 03:48:10 |
Message-ID: | 2418.1089431290@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Piskorski <atp(at)piskorski(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-07-10 04:39:52 | Re: [PATCHES] Fixes for pg_dump and ownership/acl problems |
Previous Message | Joshua D. Drake | 2004-07-10 03:08:49 | Re: [Plperlng-devel] Re: plperl security |