rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update for 7.4 --- prefer IN to EXISTS.

This commit is contained in:
Bruce Momjian 2003-10-29 20:20:12 +00:00
parent a35deb5400
commit a00d6b23eb
2 changed files with 18 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/FAQ
View File

@ -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?

14
doc/src/FAQ/FAQ.html
View File

@ -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>