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.

Collation is a new functionality of PostgreSQL 9.1 that allows to specify the sort order by table column or for an operation.

Just yesterday I committed that.

It is planned in PostgreSQL 9.2 to have support for cascading replication, which is the ability to add slaves under other slaves. In 9.2, slave-slave connections are only asynchronous.

After long weeks of battle, this week this commit has happened in Postgres-XC’s GIT repository.