This short manual targets PostgreSQL users looking for a smooth introduction to dblink.

First you need to download the latest version of Postgres-XC from here.

One of the features that has been really improved the last couple of weeks is the stabilization of remote query planning for DML for Postgres-XC standard planner. And this has consequences on rules, because a rule is fired on Coordinators by design, and you need to provide a global way to plan queries correctly with remote nodes. Just to recall, a rule is the possibility to define an alternative action when doing an INSERT, UPDATE or DELETE on a table. Another important point is that the query of a rules is not planned at the moment of the rule creation, but after rule is fired, however it doesn’t change the fact that a correct query planning is needed at a moment or another.

This year, Postgres-XC has a tutorial at PGCon. Yeah. Based on the schedule of PGCon 2012, XC team has 3 hours to make you masters of this cluster based on PostgreSQL.

Here are some thoughts about trigger events in a database cluster environment, those design thoughts are particularly related to Postgres-XC, scaling-out database cluster based on PostgreSQL.

A PostgreSQL conference has happened on the 24th of February in Tokyo, Shinagawa, event organized by JPUG (Japanese PostgreSQL user’s group). You can go to this page where all the materials of presentations are available. Most of the presentations were in Japanese, but the following ones were in English (links provided to materials if possible):

Just today this commit has happened in Postgres-XC GIT repository.

When using a database cluster where nodes are completely dependent on the network behavior like it is the case for shared-nothing based architecture, an essential step in integrating a new application is its design to maximize the performance and enhance the cluster strengths knowing its capabilities. The problem with shared-nothing architectures is that queries that may run very quickly in a single instance environment might take a bunch of time in your cluster, especially for queries having aggregates that need global results for all the nodes in the cluster or queries needing subsequent results from internal sub-queries. The nightmare of most of database developers trying to optimize an application is always to face queries of the type “SELECT *”, fetching all the tuples of a table in a single shot. Such queries are already costly for single database instances, but just don’t imagine how much you might load your application when fetching all the tuples of your table with additional node layers forcing your database to fetch results from multiple nodes. I would say by experience that there are three guidelines when customizing an application for a cluster:

This week, I spent a long time working on this commit. Just by looking at the date, commit happened before leaving for week-end :)

This week, a great feature has been added by commit 8a05756, completed by commit caf1554 in Postgres-XC GIT repository.