EMS logo


Choisissez votre outil SQL

Notre statut de partenariat

Microsoft Certified Partner
Oracle Certified Partner
Embarcadero Technology Partner

Actualités de l'industrie SQL

Tous les news SQL

PostgreSQL 8.1 beta1 is out.

Back on the 1st of July, after almost 6 months of development since 8.0 was released, development on 8.1 was frozen.

Now, after spending the past few weeks processing through outstanding patches applicable to 8.1, PostgreSQL development team now enters the beta testing period, where they need help from the community at large.

Major changes in this release:

Improve concurrent access to the shared buffer cache (Tom)

This was accomplished by eliminating global locks and using a clock sweep algorithm to find free buffers. This increases scalability on multi-CPU systems.

Allow index scans to use an intermediate in-memory bitmap (Tom)

In previous releases, only a single index could be used to do lookups on a table. With this feature, if a query has WHERE tab.col1 = 4 and tab.col2 = 9, and there is no multicolumn index on col1 and col2, but there is an index on col1 and another on col2, it is possible to search both indexes and combine the results in memory, then do heap fetches for only the rows matching both the col1 and col2 restrictions. This is very useful in environments that have a lot of unstructured queries where it is impossible to create indexes that match all possible access conditions. Bitmap scans are useful even with a single index, as they reduce the amount of random access needed; a bitmap index scan is efficient for retrieving fairly large fractions of the complete table, whereas plain index scans are not.

Add two-phase commit (Heikki Linnakangas, Alvaro, Tom)

Two-phase commit allows transactions to be "prepared" on several computers, and once all computers have successfully prepared their transactions (none failed), all transactions can be committed. Even if a machine crashes after a prepare, the prepared transaction can be committed after the machine is restarted. New syntax includes PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED. A new system view pg_prepared_xacts has also been added.

Create a new role system that replaces users and groups (Stephen Frost)

Roles are a combination of users and groups. Like users, they can have login capability, and like groups, a role can have other roles as members. Roles basically remove the distinction between users and groups. For example, a role can:

  • Have login capability (optionally)
  • Own objects
  • Hold access permissions for database objects
  • Inherit permissions from other roles it is a member of

Once a user logs into a role, she obtains capabilities of the login role plus any inherited roles, and can use SET ROLE to switch to other roles she is a member of. This feature is a generalization of the SQL standard's concept of roles. This change also replaces pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. The old tables are redefined as read-only views on the new role tables.

Automatically use indexes for MIN() and MAX() (Tom)

In previous releases, the only way to use an index for MIN() or MAX() was to rewrite the query as SELECT col FROM tab ORDER BY col LIMIT 1. Index usage now happens automatically.

Move /contrib/pg_autovacuum into the main server (Alvaro Herrera)

Integrating autovacuum into the server allows it to be automatically started and stopped in sync with the database server, and allows autovacuum to be configured from postgresql.conf.

Add shared row level locks using SELECT ... FOR SHARE (Alvaro)

While PostgreSQL's MVCC locking allows SELECT to never be blocked by writers and therefore does not need shared row locks for typical operations, shared locks are useful for applications that require shared row locking. In particular this reduces the locking requirements imposed by referential integrity checks.

Add dependencies on shared objects, specifically roles (Alvaro)

This extension of the dependency mechanism prevents roles from being dropped while there are still database objects they own. Formerly it was possible to accidentally "orphan" objects by deleting their owner. While this could be recovered from, it was messy and unpleasant.

Source: www.postgresql.org.