Awaiting of PostgreSQL 9.1 - short features review

Few weeks ago a PostgreSQL team announced the first release candidate of their powerful DBMS. It means that the release is going to be ready in several months. In the published release notes they have written following interesting information:

This release shows PostgreSQL moving beyond the traditional relational-database feature set with new, ground-breaking functionality that is unique to PostgreSQL.

From my point of view this is not just marketing words because every PostgreSQL major release always contained really  significant changes, which gives us high expectations for future releases as well. So, what are real advantages we might get from version 9.1 once it's released?

First of all, we might be able to choose what replication type we want to use (if there is any need in it at all) - either asynchronous (or streaming), which has been added in 9.0, or synchronous, available in the following release.

Asynchronous replication is faster than synchronous because it sends transactions to the standby server immediately as they are generated and doesn't wait them to be written into the transaction log, but synchronous replication gives us guarantee that all committed transactions are available on standby, because it uses some kind of two phase commit which doesn't mark a transaction as committed until it is written into the transaction logs on both servers - master and slave.
As a bonus, a special replication monitoring tool presented as simple system view table pg_stat_replication has been added. It contains the statuses of all connected standby servers.

Worth adding that PostgreSQL team has added an amazing enhancement named unlogged tables. It allows us to create a special table - all data inserted, updated or deleted in this table don't affect transaction log at all, so any transaction operating only with this kind of tables works faster than a ordinary table transaction. Next big plus is that an unlogged table is not replicated to standby servers. Unlike a temp table an unlogged table stays in the database and keeps data until it's dropped, but there is no crash-recovery mechanism which means that an unlogged table is automatically truncated after any crash or unclean shutdown.

The next interesting feature is creation of foreign tables. Using them we're able to "map" tables (like writable view) from other databases, using special foreign data wrappers. We might be able to map tables from different instances of PostgreSQL, or, with third-party wrappers, from MySQL or even Oracle! It gives us possibility of working with tables from different databases more transparent and might make your migration to PostgreSQL little bit easier.
For instance, foreign data wrapper for mapping simple text files has already been included in the default PostgreSQL 9.1 installer, so we might read CSV files as tables immediately after installation executing simple query (as database superuser, of course):

CREATE EXTENSION file_fdw;

Oh, about extensions - this feature is added to 9.1 as well. As PostgreSQL team stated that extensions serve to simplify packaging of any additions to PostgreSQL. This improvement allows to add as one entity a lot of complex queries creating all stored procedures, types, operators and other stuff used to import different modules into the database. Since 9.1 all default contributed modules and stored procedure languages use this mechanism to be installed.

Let's look what improvements in database objects manipulation are waiting for us in this version.

I would like to pay your attention to a new ability of creation the primary key constraint using existing index! Now, if there is a need to reindex primary key index or create new one "on the fly" - just create a new unique index concurrently (lockless!) then just drop old constraint, if there was any, and add a new one, based on created index.

Next interesting thing is a changing data type in the specified column of selected table without full table rewriting, but only in particular cases. A quote from documentation: "For example, converting a varchar column to text no longer requires a rewrite of the table. However, increasing the length constraint on a varchar column still requires a table rewrite.".

Another important enhancement is ability to add foreign keys without validation. I think this feature has been added not only to improve the performance of the creation foreign keys and make it lockless. Just a few days ago I had tried to create a foreign key pointed to the partitioned table (one empty master table and children tables inherited from it, with data from inserts to the master table with rules) but I got an error, because this table did not contain any data and foreign key validation didn't accept my query. But why did I need it? I wanted to be sure that all linked data will be deleted when I delete it from partitioned table. With 9.1 I might can do it - creating a foreign key constraint without validation with the primary key.

Another amazing thing is adding third type of trigger firing. In addition to BEFORE and AFTER you can use INSTEAD OF firing case, which means that might be able to transparently deliver data from one table to another, just like rules usage. This feature might be useful to implement fully updatable views.

A little bit of other interesting features:

1. Like to use WITH clause in queries? Great news everyone! Now we can use data-modification commands in that clause, unfortunately only if there is RETURNING clause. We might be able to modify some data and get the information we want (for example, using grouping) in one query.

2. GiST indexes got a new operator, allowing return nearest-neighbor data. Quote from documentation:

This allows GiST indexes to quickly return the N closest values in a query with LIMIT. For example

SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;

finds the ten places closest to a given target point.

3. Config option wal_buffers now is auto-tuned by default. It's based on the size of the config option shared_buffers. One more configuration option that don't need to tune after installation!

UPD:
Release Date: 2011-09-12