From e889ff4def0771435ae6e0b33baf565c797a51c5 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Tue, 23 Aug 2005 12:47:30 +0000
Subject: [PATCH] Release note updates.

---
 doc/src/sgml/release.sgml | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index 22c2bd52b1..4a6793e029 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.343 2005/08/23 12:46:35 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.344 2005/08/23 12:47:30 momjian Exp $
 -->
 
 <appendix id="release">
@@ -30,21 +30,22 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.343 2005/08/23 12:46:35 momjian
       <listitem>
        <para>
         This was accomplished by eliminating global locks and using a clock
-       sweep algorithm to find free buffers.
+       sweep algorithm to find free buffers. This increases scalability
+       on multi-CPU systems.
        </para> 
       </listitem>
      </varlistentry>
 
      <varlistentry>
       <term>
-       Allow indexes to be used for MIN/MAX (Tom)
+       Automatically use indexes for MIN() and MAX() (Tom)
       </term>
  
       <listitem>
        <para>
-        In previous releases, the only way to use index for MIN/MAX was to rewrite
-        the query as SELECT col FROM tab ORDER BY col LIMIT 1. This now happens
-        automatically.
+        In previous releases, the only way to use an index for MIN/MAX
+        was to rewrite the query as SELECT col FROM tab ORDER BY col
+        LIMIT 1. Index usage now happens automatically.
        </para> 
       </listitem>
      </varlistentry>
-- 
GitLab