From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | 8.2 features status |
Date: | 2006-08-04 03:54:10 |
Message-ID: | 1551.1154663650@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm not clear on why there's all this doom and gloom about how 8.2 will
be "merely" a performance-oriented release, with few new features, eg
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php
Certainly there's been a ton of effort spent on high-end performance
issues. But a quick troll through the CVS logs shows a fair number of
features that could be considered killer must-have things by their
respective target audiences:
multi-row VALUES, not only for INSERT but everywhere SELECT is allowed
pg_dump multiple -n and -t options, regex patterns for object names
multi-argument aggregates, including SQL2003-standard statistical aggregates
fully configurable timezone abbreviations (no more 'australian_timezones' hack)
allow full zic timezone names in datetime input values
support comparisons like "if row(new.*) is distinct from row(old.*)"
DROP ... IF EXISTS
numerous tsearch2 improvements, eg thesaurus
GIN index opclass
GRANT CONNECT ON DATABASE
support SSL Certificate Revocation List (CRL) files
plpython supports named parameters, composite-type results, more result-set options
plperl prepared queries
domain constraint checks are now applied everywhere
better psql multiline command handling
error cursor position displayed for many parse-analysis errors
standard_conforming_strings can be turned on (HUGE deal for some people)
initdb and pg_ctl can safely start from an admin account on Windows
display multiline values nicely in psql
support SQL-compliant row comparisons; they can be indexscan quals
DROP OWNED, REASSIGN OWNED for dealing with removal of a user
null elements in arrays
There are also some commits that are "mere" performance tweaks, and yet
we should not understate their importance because they could make the
difference between usability and non-usability in many applications:
lazy vacuums are ignored by other processes; improves behavior of concurrent vacuums
add index and table storage options (currently only FILLFACTOR)
stats_command_string overhead reduced to near zero, now on by default
reduce locking involved in DATABASE commands, eg CREATE DATABASE no longer blocks incoming connections
constraint exclusion works for UPDATE and DELETE
constraint exclusion works for UNION ALL views, not only inheritance trees
planner can rearrange join order for many common OUTER JOIN scenarios
And that's not counting some pretty significant submitted-but-not-yet-
reviewed patches (sure, some of these may get rejected, but they're all
open possibilities today):
online index builds
bitmap index AM
updatable views
PL plugin patch (plpgsql debugger infrastructure)
restartable recovery (allow checkpoints for a hot-standby server)
INSERT/UPDATE RETURNING
Not that there's anything wrong with a performance-oriented release
... but if you think that 8.2 is short on features, you'd better get
ready to be disappointed by every future release. There's not all
that much stuff left to do in terms of raw language "features".
(Of course the SQL committee keeps inventing a ton of new stuff every
few years, but how much of that do you really care about?)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-08-04 04:00:25 | Re: 8.2 features status |
Previous Message | Bruce Momjian | 2006-08-04 03:45:18 | New ecpg warnings |