diff options
author | Bruce Momjian <bruce@momjian.us> | 2006-02-24 14:59:54 +0000 |
---|---|---|
committer | Bruce Momjian <bruce@momjian.us> | 2006-02-24 14:59:54 +0000 |
commit | 0915d370f549e68ec56cf819d0023bb2c237603d (patch) | |
tree | a4488b188940a85142e7c7c2b468320062e09a43 /doc/FAQ | |
parent | eb8f9cc066dd0c9642a6101a833b6e0d698c2a6b (diff) | |
download | postgresql-0915d370f549e68ec56cf819d0023bb2c237603d.tar.gz postgresql-0915d370f549e68ec56cf819d0023bb2c237603d.zip |
Remove mention of MIN/MAX() not using indexes.
Diffstat (limited to 'doc/FAQ')
-rw-r--r-- | doc/FAQ | 12 |
1 files changed, 3 insertions, 9 deletions
@@ -1,7 +1,7 @@ Frequently Asked Questions (FAQ) for PostgreSQL - Last updated: Sun Feb 12 12:15:49 EST 2006 + Last updated: Fri Feb 24 09:59:35 EST 2006 Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) @@ -569,14 +569,8 @@ sequential scan followed by an explicit sort is usually faster than an index scan of a large table. However, LIMIT combined with ORDER BY often will use an index because - only a small portion of the table is returned. In fact, though MAX() - and MIN() don't use indexes, it is possible to retrieve such values - using an index with ORDER BY and LIMIT: - SELECT col - FROM tab - ORDER BY col [ DESC ] - LIMIT 1; - + only a small portion of the table is returned. + If you believe the optimizer is incorrect in choosing a sequential scan, use SET enable_seqscan TO 'off' and run query again to see if an index scan is indeed faster. |