Re: PGCluster-II Progress

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: Marcos Luis Ortiz Valmaseda <mlortiz(at)uci(dot)cu>
Cc: Serge Fonville <serge(dot)fonville(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PGCluster-II Progress
Date: 2009-09-15 15:14:39
Message-ID: 36e682920909150814x6fa624d3w17a74c0f4c6322fc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 15, 2009 at 7:48 AM, Marcos Luis Ortiz Valmaseda <mlortiz(at)uci(dot)cu
> wrote:

> Yeah, the problem here is that CyberCluster is based yet on PostgreSQL 8.1
> and is a very old version to use it.
>
> I found the developer of PgCluster-II: Atsushi MITANI - mitani(at)sraw(dot)co(dot)jp

Yeah, AFAICS, PGCluster II is and has been dead for years.

I did an architectural review of PGCluster II while at EnterpriseDB, and
it's never going to work from a performance perspective. Unfortunately, the
architecture (as it stands) requires coordination of pretty much all locks
and semaphores, and will only run on a single system because it requires a
nearly-identical shared memory segment for each instance. Unlike Oracle
RAC, which was designed to be run on separate nodes and share/coordinate
only relevant resources, PGCluster II coordinates almost everything
(transaction ids, buffer locks, etc.).

As an example, Oracle doesn't need to communicate with every node in the
cluster to generate a new transaction id (SCN in Oracle parlance) because it
employs a system based on Lamport timestamps, but PGCluster II has to
coordinate a global transaction id across all nodes.

Also, PGCluster II has no concept of shared data/local WAL. Whereas Oracle
supports threads of REDO/UNDO generated by the local node, all WAL in
PGCluster II has to be coordinated between nodes, which creates a bottleneck
on *all* concurrent workloads.

When I first saw the demonstration of PGCluster II, I was in awe.
Unfortunately, when I reviewed the architecture, I saw that it was too good
to be true. Perhaps it has been rearchitected in private to overcome some
of these issues, but I'm not aware of it. All attempts to talk to Atsushi
about it were met with no response.

--
Jonah H. Harris, Senior DBA
myYearbook.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2009-09-15 15:32:19 Re: Timestamp to time_t
Previous Message Andrew Gierth 2009-09-15 15:10:43 Re: Timestamp to time_t