Thread: Release Notes Overview

Release Notes Overview

From
Simon Riggs
Date:
My suggested edit of the Overview section of the Release Notes. The
emphasis is on user-noticeable features, so some of the major internal
changes are lower down the list. Some items have been removed or placed
below the performance features.


New data types for SQL/XML, enum and uuid types

Updateable Cursors, plus support in PL/pgSQL. PostgreSQL now supports
all major items of Core SQL:2003 compatibility.

Full text Search is now a built-in feature, so .... is easier/better

Asynchronous Commit allows some transactions to commit faster than
others, offering a trade-off between performance and durability for
specific transaction types only

Database Size reductions both per-row and per-field

Additional security features: GSSAPI/SSPI and easier to implement
security-definer functions using per function SET parameters

New ORDER BY ... NULLS FIRST/LAST option and matching support for
indexes allows easier migration of applications from other RDBMS

Better scalability and more consistent response times come from
systematic removal of internal contention points within the server

Performance improvements in many important workloads

- update-intensive workloads now avoid index inserts via a new internal
mechanism known as HOT, plus multiple concurrent auto-vacuum processes
maintain the database more consistently

- initial data loads now avoid writing WAL, plus all data loads use less
CPU than previously

- large table scans by optimising cache usage and allowing multiple
synchronous scans to reuse the same data, avoiding I/O

- short read-only transactions give reduced costs and higher scalability
using lazy transactionid assignment 

Tracking of internal activity has many additional features, improving
your ability to design, manage and maintain the database

Self-adjusting background writer helps write-intensive workloads

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Release Notes Overview

From
Gregory Stark
Date:
"Simon Riggs" <simon@2ndquadrant.com> writes:

> Asynchronous Commit allows some transactions to commit faster than
> others, offering a trade-off between performance and durability for
> specific transaction types only

A lot of users will be confused about what asynchronous commit does. I think
it's important to be consistently precise when describing it. 

It doesn't allow commits to be any faster, what it does is "allow clients to
start a new transaction and continue working without waiting for their
previous commit to complete". Saying something like "This allows high volumes
of short transactions such as typical web sites to run more efficiently and
with fewer connections" might also help clarify the use case it helps.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


Re: Release Notes Overview

From
Simon Riggs
Date:
On Fri, 2007-10-05 at 11:24 +0100, Gregory Stark wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> 
> > Asynchronous Commit allows some transactions to commit faster than
> > others, offering a trade-off between performance and durability for
> > specific transaction types only
> 
> A lot of users will be confused about what asynchronous commit does. I think
> it's important to be consistently precise when describing it. 
> 
> It doesn't allow commits to be any faster, what it does is "allow clients to
> start a new transaction and continue working without waiting for their
> previous commit to complete". Saying something like "This allows high volumes
> of short transactions such as typical web sites to run more efficiently and
> with fewer connections" might also help clarify the use case it helps.

The general shape of the overview was what I was looking at. 

I agree with your specific comment.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Release Notes Overview

From
Bruce Momjian
Date:
Gregory Stark wrote:
> 
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> 
> > Asynchronous Commit allows some transactions to commit faster than
> > others, offering a trade-off between performance and durability for
> > specific transaction types only
> 
> A lot of users will be confused about what asynchronous commit does. I think
> it's important to be consistently precise when describing it. 
> 
> It doesn't allow commits to be any faster, what it does is "allow clients to
> start a new transaction and continue working without waiting for their
> previous commit to complete". Saying something like "This allows high volumes
> of short transactions such as typical web sites to run more efficiently and
> with fewer connections" might also help clarify the use case it helps.

Well, logically the commit does happen faster in that your transaction
and others see the commit.  It is just durability that is delayed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +