public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Markus Schiltknecht <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: [Pgcluster-general] PostgreSQL Documentation of
Date: Tue, 21 Nov 2006 22:44:34 -0500 (EST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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   [email protected]
  EnterpriseDB    http://www.enterprisedb.com

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

view thread (25+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [Pgcluster-general] PostgreSQL Documentation of
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox