diff options
| -rw-r--r-- | doc/FAQ | 18 | ||||
| -rw-r--r-- | doc/src/FAQ/FAQ.html | 14 |
2 files changed, 18 insertions, 14 deletions
@@ -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 30c03d468c1..b01bbef36ed 100644 --- 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> |