This is an overview of new features in 8.1.0 against 8.0.x. 8.1.3 includes
many bug fixes since 8.1.0. Please read documentation of the detailed changes
and procedure of data migration.
Overview
Major changes in this release:
Improve concurrent access to the shared buffer cache (Tom)
Access to the shared buffer cache was identified as a
significant scalability problem, particularly on multi-CPU
systems. In this release, the way that locking is done in the
buffer manager has been overhauled to reduce lock contention and
improve scalability. The buffer manager has also been changed to
use a "clock sweep" replacement policy.
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)
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.
Improve performance for partitioned tables (Simon)
The new constraint_exclusion configuration parameter avoids
lookups on child tables where constraints indicate that no
matching rows exist in the child table.
This allows for a basic type of table partitioning. If child
tables store separate key ranges and this is enforced using
appropriate "CHECK" constraints, the optimizer will skip child
table accesses when the constraint guarantees no matching rows
exist in the child table.
martti
uebayasi