From: Bruce Momjian <bruce@momjian.us>
Message-Id: <200611220344.kAM3iYh14068@momjian.us>
Subject: Re: [Pgcluster-general] PostgreSQL Documentation of
In-Reply-To: <4562B799.7090209@bluegap.ch>
To: Markus Schiltknecht <markus@bluegap.ch>
Date: Tue, 21 Nov 2006 22:44:34 -0500 (EST)
CC: a.mitani@sra-europe.com, pgsql-docs@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Markus Schiltknecht wrote:
> Hello Bruce,
> 
> Bruce Momjian wrote:
> > OK, but how does explaining the terms help our users?
> 
> As we even have on sort-of-a solution for shared disk clusters (the 
> Shared Disk Failover part), we should explain this term (as you already 
> do there).
> 
> Clarifying that all other solutions are for shared nothing clusters 
> makes sense, IMO. We don't necessarily need to go into shared memory and 
> the confusion which shared everything introduced. OTOH, where else to 
> enlighten people about that if not in such a documentation?
> 
> To answer your question: by explaining these terms, they are 
> demystified. The users will understand the experts better and have some 
> fundamental terms which they can base their discussion on. Of course 
> it's questionable how far to go, and we are debating just that now, I think.
> 
> But I have no doubt in the OSS tradition of good documentation. Long 
> live the saying 'RTFM'! :-)

I figured that shared-disk/memory only really makes sense for
multi-master clustering, so I mentioned it in that paragraph:

  <term>Multi-Master Clustering</term>
  <listitem>

   <para>
    In clustering, each server can accept write requests, and
    modified data is transmitted from the original server to every
    other server before each transaction commits.  Heavy write
    activity can cause excessive locking, leading to poor performance.
    In fact, write performance is often worse than that of a single
->    server.  Read requests can be sent to any server.  Some
->    implementations use cluster-wide shared memory or shared disk
->    to reduce the communication overhead.  Clustering is best for
    mostly read workloads, though its big advantage is that any
    server can accept write requests &mdash; there is no need to
    partition workloads between master and slave servers, and
    because the data changes are sent from one server to another,
    there is no problem with non-deterministic functions like
    <function>random()</>.

Is that enought?

-- 
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +