Re: postgresql clustering

Jonah H. Harris schrieb:
> On 9/29/05, *Tino Wildenhain* <tino(at)wildenhain(dot)de
> <mailto:tino(at)wildenhain(dot)de>> wrote:
>
> Well, I dont know why many people believe parallel execution
> automatically means high performance. Actually most of the time
> the performance is much worser this way.
> If your dataset remains statically and you do only read-only
> requets, you get higher performance thru load-balancing.
> If howewer you do some changes to the data, the change has to
> be propagated to all nodes - which in fact costs performance.
> This highly depends on the link speed between the nodes.
>
>
> I think you should clarify that the type of clustering you're discussing
> is the, "shared-nothing" model which is most prevalent in open-source
> databases. Shared-disk and shared-memory clustered systems do not have
> the "propagation" issue but do have others (distributed lock manager,
> etc). Don't make blind statements. If you want more information about
> "real-world" clustering, read the research for DB2 (Mainframe) and
> Oracle RAC.

No, thats not a blind statement ;) It does not matter how the
information is technically shared - shared mem must be
copied or accessed over network links if you have more then
one independend system. Locks are informations too - thus the
same constraints apply.

So no matter how you label the problem, the basic constraints:
read communication and synchronisation overhead will remain.

Costom solutions can circumvent some of the problems if you
can shift the problem area (e.g. have some read-only areas,
some seldom-write areas and some high write, some seldom read
and not immediately propagated data)