From: Bruce Momjian <bruce@momjian.us>
Date: Wed, 30 May 2001 23:00:41 +0000 (+0000)
Subject: Update FAQ.
X-Git-Tag: REL7_2_BETA1~1136
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=227a584655edcf16e98d0f986fbda0c4abd6b991;p=postgresql

Update FAQ.
---

diff --git a/doc/FAQ b/doc/FAQ
index f59d74ff9a..7224c15f77 100644
--- a/doc/FAQ
+++ b/doc/FAQ
@@ -1,7 +1,7 @@
 
                 Frequently Asked Questions (FAQ) for PostgreSQL
                                        
-   Last updated: Wed May 30 18:57:52 EDT 2001
+   Last updated: Wed May 30 19:00:33 EDT 2001
    
    Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
    
@@ -709,9 +709,9 @@ Maximum number of indexes on a table?    unlimited
    column statistics on its own, so VACUUM ANALYZE must be run to collect
    them periodically.
    
-   Indexes are usually not used for ORDER BY or joins: a sequential scan
+   Indexes are usually not used for ORDER BY or joins. A sequential scan
    followed by an explicit sort is faster than an indexscan of all tuples
-   of a large table, because it takes fewer disk accesses.
+   of a large table. This is because random disk access is very slow.
    
    When using wild-card operators such as LIKE or ~, indices can only be
    used if the beginning of the search is anchored to the start of the
diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index 932b2b7856..aba74b0e93 100644
--- a/doc/src/FAQ/FAQ.html
+++ b/doc/src/FAQ/FAQ.html
@@ -12,7 +12,7 @@
   alink="#0000FF">
     <H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
 
-    <P>Last updated: Wed May 30 18:57:52 EDT 2001</P>
+    <P>Last updated: Wed May 30 19:00:33 EDT 2001</P>
 
     <P>Current maintainer: Bruce Momjian (<A href=
     "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
@@ -908,9 +908,9 @@ Maximum number of indexes on a table?    unlimited
     periodically.</P>
 
     <P>Indexes are usually not used for <SMALL>ORDER BY</SMALL>
-    or joins: a sequential scan followed by an explicit sort is
-    faster than an indexscan of all tuples of a large table, because it
-    takes fewer disk accesses.</P>
+    or joins.  A sequential scan followed by an explicit sort is
+    faster than an indexscan of all tuples of a large table.  This
+    is because random disk access is very slow.</P>
 
     <P>When using wild-card operators such as <SMALL>LIKE</SMALL> or
     <I>~,</I> indices can only be used if the beginning of the search