Thread: Architecture

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?  This is site specific, but
most production environments require far more reading than writing, and this
would allow smaller, faster (perhaps) readers to be started, while only
opening the writers when necessary.  In fact, only one writer could be used,
as a daemon possibly, with perhaps slave writers where viable.
Also, this would allow administrators to further optimise the operation of
the database, and it would be a step closer to a parallel architecture.
Imagine being able to run two servers with readers only, and one server with
a writer, and auxillary reader, all serving up the same database!

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?

I know that a good network comms/signalling library would be needed to do
some of this stuff.  Would it not be worthwhile to try coaxing one of the
open source products (perhaps ACE, I don't know of any others: does it have
a C interface) to supporting all the platforms that PG does?

Any thoughts....


MikeA

"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