From a00d6b23ebc27d66a090554e2e8c95fb0c26b9e6 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Wed, 29 Oct 2003 20:20:12 +0000 Subject: Update for 7.4 --- prefer IN to EXISTS. --- doc/src/FAQ/FAQ.html | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) (limited to 'doc/src') 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">

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)
@@ -1303,10 +1303,10 @@ BYTEA bytea variable-length byte array (null-byte safe)

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 +

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 *
@@ -1320,7 +1320,9 @@ BYTEA           bytea           variable-length byte array (null-byte safe)
For this to be fast, subcol should be an indexed column. - This preformance problem will be fixed in 7.4. +

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?

-- cgit v1.2.3