mirror of
https://github.com/postgres/postgres.git
synced 2025-04-24 10:47:04 +03:00
Back out release changes that weren't ready for commit.
This commit is contained in:
parent
688b3aac49
commit
29eece51a8
@ -1,4 +1,4 @@
|
|||||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.516 2007/10/10 13:43:42 momjian Exp $ -->
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.517 2007/10/10 14:09:49 momjian Exp $ -->
|
||||||
<!--
|
<!--
|
||||||
|
|
||||||
Typical markup:
|
Typical markup:
|
||||||
@ -48,16 +48,14 @@ do it for earlier branch release files.
|
|||||||
<title>Overview</title>
|
<title>Overview</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This release adds major new capabilities to the
|
This release adds many improvements that were requested by users,
|
||||||
<productname>PostgreSQL</> database system, including:
|
|
||||||
including:
|
including:
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Full text search now fully integrated into the core database
|
Full text search is now a built-in feature
|
||||||
system
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -70,14 +68,13 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Enumerated (enum) data types
|
enum data types
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Universally Unique Identifier (UUID) data type, similar to that
|
UUID data type, similar to that defined by RFC 4122
|
||||||
defined by RFC 4122
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -89,34 +86,32 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Control of whether <literal>NULL</>s sort first or last, using
|
|
||||||
<literal>ORDER BY ... NULLS FIRST/LAST</>
|
<literal>ORDER BY ... NULLS FIRST/LAST</>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Updatable cursors using <literal>UPDATE/DELETE WHERE CURRENT OF</>
|
Updatable cursors
|
||||||
<replaceable>cursor_name</>
|
(<literal>UPDATE/DELETE WHERE CURRENT OF</>
|
||||||
|
<replaceable>cursor_name</>)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Per-function server configuration parameter settings
|
Per-function parameter settings
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
User-defined types can now have type modifiers
|
User-defined types can now have type modifiers (parameters)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This allows a user type to take an optional modifier when
|
Declarations such as <type>varchar(42)</type> are no longer
|
||||||
being created, e.g. <type>SSNUM(7)</>. Previously only
|
restricted to use by built-in data types.
|
||||||
predefined system data types would allow this, e.g.
|
|
||||||
<type>CHAR(4)</>.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -133,10 +128,10 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Numerous improvements in logging and statistics collection,
|
Numerous improvements in logging and statistics collection
|
||||||
including the ability to emit postmaster log messages in
|
capabilities, including the ability to emit postmaster log messages
|
||||||
<acronym>CSV</> format, which can be loaded into a database
|
in CSV format that can be directly loaded into a database table
|
||||||
table for analysis
|
for analysis
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -152,24 +147,21 @@ do it for earlier branch release files.
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This allows multiple vacuums to run concurrently, meaning
|
Autovacuum is now considered mature enough to be enabled by default.
|
||||||
vacuuming of a large table will not prevent smaller tables from
|
|
||||||
being vacuumed at the same time. Autovacuum is now considered
|
|
||||||
mature and therefore is enabled by default.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The backend database server can now be compiled with
|
The entire <productname>PostgreSQL</productname> system can
|
||||||
<productname>Microsoft Visual C++</>
|
now be compiled with Microsoft Visual C++
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Windows executables made with Visual C++ might have better
|
This will improve the ability of Windows-based developers to
|
||||||
stability and performance than those made with other tool sets.
|
contribute to the project. Windows executables made with Visual C++
|
||||||
Development and debugging tools familiar to Windows developers
|
may also have better stability and performance than those made with
|
||||||
will also work.
|
other tool sets.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -181,41 +173,32 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Asynchronous commit option allows transactions to be committed
|
Asynchronous commit option to allow transactions to be reported
|
||||||
but on-disk change to be delayed
|
committed before they have actually been flushed to disk
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This feature dramatically increases performance for data
|
This would not, of course, be acceptable if the client takes some
|
||||||
modification queries. The disadvantage is that because on-disk
|
critical external action on the assumption that the transaction
|
||||||
changes are delayed, if the operating system crashes before data
|
will be remembered; but for certain applications, it is an acceptable
|
||||||
is written to the disk, committed data will be lost. This is
|
risk for some or all transactions to use this mode. Unlike existing
|
||||||
only useful for applications that can accept some data loss.
|
options such as <varname>fsync</varname>, asynchronous commit does
|
||||||
Unlike <varname>fsync</varname>, asynchronous commit does not
|
not risk database corruption; the worst case is that after a crash,
|
||||||
risk database corruption; the worst case is that after an
|
the last few reportedly-committed transactions will not have
|
||||||
operating system crash, the last few reportedly-committed
|
taken effect.
|
||||||
transactions will be missing.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<quote>Distributed</> checkpoints prevent I/O spikes during
|
<quote>Distributed</> checkpoints to spread out the I/O load of a
|
||||||
checkpoints
|
checkpoint
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Heap-Only Tuples (<acronym>HOT</>) reduce overhead of updates
|
Heap-Only Tuples (HOT) to reduce overhead of updates
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
To allow high concurrency <productname>PostgreSQL</> retains old
|
|
||||||
versions of updated rows. Previously only <command>VACUUM</>
|
|
||||||
could reuse space taken by dead rows. With <acronym>HOT</> dead
|
|
||||||
row space can be reused at the time of <command>UPDATE</> or
|
|
||||||
<command>INSERT</>. This allows for more consistent performance.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -224,21 +207,12 @@ do it for earlier branch release files.
|
|||||||
Just-in-time background writer strategy to improve disk write
|
Just-in-time background writer strategy to improve disk write
|
||||||
efficiency
|
efficiency
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
This basically makes the background writer self-tuning.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Reduction of both per-field and per-row storage requirements
|
Reduction of on-disk data size through reducing both per-tuple
|
||||||
</para>
|
and per-field overheads
|
||||||
|
|
||||||
<para>
|
|
||||||
For example, two <type>CHAR(1)</type> fields now take 4 bytes
|
|
||||||
instead of 16.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user