Update for 7.4 --- prefer IN to EXISTS.

diff --git a/doc/FAQ b/doc/FAQ
index a98ec3112300db920b754eb1c8a7698ac0891c86..bec9455b98060f5e6404c7b6304364e58d181cc2 100644 (file)
--- a/doc/FAQ
+++ b/doc/FAQ
@@ -1,7 +1,7 @@
 
                 Frequently Asked Questions (FAQ) for PostgreSQL
                                        
-   Last updated: Fri Oct 10 17:27:02 EDT 2003
+   Last updated: Wed Oct 29 15:19:43 EST 2003
    
    Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
    
@@ -1031,11 +1031,11 @@ CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
 
     4.22) Why are my subqueries using IN so slow?
     
-   Currently, we join subqueries to outer queries by sequentially
-   scanning the result of the subquery for each row of the outer query.
-   If the subquery returns only a few rows and the outer query returns
-   many rows, IN is fastest. To speed up other queries, replace IN with
-   EXISTS:
+   In versions prior to 7.4, subqueries were joined to outer queries by
+   sequentially scanning the result of the subquery for each row of the
+   outer query. If the subquery returns only a few rows and the outer
+   query returns many rows, IN is fastest. To speed up other queries,
+   replace IN with EXISTS:
     SELECT *
     FROM tab
     WHERE col IN (SELECT subcol FROM subtab);
@@ -1045,8 +1045,10 @@ CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
     FROM tab
     WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);
 
-   For this to be fast, subcol should be an indexed column. This
-   preformance problem will be fixed in 7.4.
+   For this to be fast, subcol should be an indexed column.
+   
+   In version 7.4 and later, IN actually uses the same sophisticated join
+   techniques as normal queries, and is prefered to using EXISTS.
    
     4.23) How do I perform an outer join?
     

diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index 30c03d468c121f459515d0838ee761ddc7a0ac39..b01bbef36ed6aed63c9ef7018eea7a8eac4db3e4 100644 (file)
--- a/doc/src/FAQ/FAQ.html
+++ b/doc/src/FAQ/FAQ.html
@@ -10,7 +10,7 @@
   alink="#0000ff">
     <H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
 
-    <P>Last updated: Fri Oct 10 17:27:02 EDT 2003</P>
+    <P>Last updated: Wed Oct 29 15:19:43 EST 2003</P>
 
     <P>Current maintainer: Bruce Momjian (<A href=
     "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
@@ -1303,10 +1303,10 @@ BYTEA           bytea           variable-length byte array (null-byte safe)
     <H4><A name="4.22">4.22</A>) Why are my subqueries using
     <CODE><SMALL>IN</SMALL></CODE> so slow?</H4>
 
-    <P>Currently, we join subqueries to outer queries by sequentially
-    scanning the result of the subquery for each row of the outer
-    query. If the subquery returns only a few rows and the outer query
-    returns many rows, <CODE><SMALL>IN</SMALL></CODE> is fastest.  To
+    <P>In versions prior to 7.4, subqueries were joined to outer queries
+    by sequentially scanning the result of the subquery for each row of
+    the outer query. If the subquery returns only a few rows and the outer
+    query returns many rows, <CODE><SMALL>IN</SMALL></CODE> is fastest.  To
     speed up other queries, replace <CODE>IN</CODE> with
     <CODE>EXISTS</CODE>:</P>
 <PRE>    SELECT *
@@ -1320,7 +1320,9 @@ BYTEA           bytea           variable-length byte array (null-byte safe)
 </PRE>
 
     For this to be fast, <CODE>subcol</CODE> should be an indexed column.
-    This preformance problem will be fixed in 7.4.
+    <P>In version 7.4 and later,  <CODE>IN</CODE> actually uses the same
+    sophisticated join techniques as normal queries, and is prefered
+    to using <CODE>EXISTS</CODE>.
 
     <H4><A name="4.23">4.23</A>) How do I perform an outer join?</H4>