On Tue, Sep 15, 2009 at 7:48 AM, Marcos Luis Ortiz Valmaseda
<mlortiz@uci.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@sraw.co.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