From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | koichi(dot)szk(at)gmail(dot)com |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Eliot Gable <egable+pgsql-hackers(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Horizontal Write Scaling |
Date: | 2010-11-25 15:06:39 |
Message-ID: | AANLkTikCYE-FkQ97Vw7sS_mQe17hKhpVZHe4Y9UjnqGQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 25, 2010 at 4:45 AM, Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com> wrote:
>>> plus the
>>> communication protocol overhead and latency. However, it occurs to me
>>> that if you had a shared disk system via either iSCSI, Fiber Channel,
>>> NFS, or whatever (which also had higher I/O capabilities than a single
>>> server could utilize), if you used a file system that supported locks on
>>> a particular section (extent) of a file, it should theoretically be
>>> possible for multiple Postgres instances on multiple systems sharing the
>>> database to read and write to the database without causing corruption.
>>
>> Possible, yes. Worthwile to do, probably not.
>
> We may be suffered from synchronizing cache on each database.
That's putting it mildly. You have to worry about the database buffer
cache, the shared invalidation queue, the control file data, the
ProcArray, the lock manager, the LWLock tables, and probably some
other things I'm forgetting about. Everything in shared memory, in
short.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-25 15:07:56 | Re: reporting reason for certain locks |
Previous Message | Alvaro Herrera | 2010-11-25 15:05:00 | Re: reporting reason for certain locks |