"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> If I understand things right, the postgres process is both a reader and
> writer. Is this right? If it is, would there be any value in separating
> the reader and writer portions of the program?
Right offhand I don't see where there would be any real benefit to be
gained. It's true that you could make a smaller Postgres executable
if you stripped out writing (the same goes for a lot of other features
arguably not needed very often...) But on modern platforms it's not a
win to make multiple variants of an executable file. You're better off
with one executable that will be shared as an in-memory image by all the
processes running Postgres.
> By the way, is it possible to run two postgres servers using the same
> database shared using NFS or SMB or something? Probably not, but why not?
The main problem is interprocess interlocking. Currently we rely on
shared memory and SysV-style semaphores, which means all the Postgres
processes need to be on the same Unix system. (Making some of them
reader-only wouldn't help; they still need to be involved in locking.)
You could conceivably have the database files themselves be NFS-mounted
by that system, but I doubt it'd be a performance win to do so.
Spreading the servers across multiple machines would almost certainly
be a big loss because of the increased cost of communication for
locking. OTOH, a multi-CPU Unix box could be a real big win.
regards, tom lane