Re: postgresql clustering

[Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>]

Luke Lonergan wrote:
> Dan,
>
> On 9/29/05 3:23 PM, "Daniel Duvall" <the(dot)liberal(dot)media(at)gmail(dot)com> wrote:
>
>
> > What about clustered filesystems?  At first blush I would think the
> > overhead of something like GFS might kill performance.  Could one
> > potentially achieve a fail-over config using multiple nodes with GFS,
> > each having there own instance of PostgreSQL (but only one running at
> > any given moment)?
>
>
> Interestingly - my friend Matt O'Keefe built GFS at UMN, I was one of his
> first customers/sponsors of the research in 1998 when I implemented an
> 8-node shared disk cluster on Alpha Linux using GFS and Fibre Channel.
>
> Again - it depends on what you're doing - if it's OLTP, you will spend too
> much time in lock management for disk access and things like Oracle RAC's
> CacheFusion becomes critical to reduce the number of times you have to hit
> disks.  


Hitting the disk is really bad. However, we have seen that consulting 
the network for small portions of data (e.g. locks) is even more 
critical. you will see that the CPU on all nodes is running at 1% or so 
while the network is waiting for data to be exchanged (latency) - this 
is the real problem.

i don't know what oracle is doing in detail but they have real problem 
when losing a node inside the cluster (syncing again is really time 
consuming).


> For warehousing/sequential scans, this kind of clustering is
> irrelevant.

I suggest to look at Teradata - for do really nice query partitioning on 
so called AMPs (we'd simply call it node). It is really nice for really 
ugly warehousing queries (ugly in terms of amount of data).

	Hans



--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at