Skip to content
Snippets Groups Projects
Commit 0915d370 authored by Bruce Momjian's avatar Bruce Momjian
Browse files

Remove mention of MIN/MAX() not using indexes.

parent eb8f9cc0
No related branches found
No related tags found
No related merge requests found
Frequently Asked Questions (FAQ) for PostgreSQL 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) Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
...@@ -569,14 +569,8 @@ ...@@ -569,14 +569,8 @@
sequential scan followed by an explicit sort is usually faster than an sequential scan followed by an explicit sort is usually faster than an
index scan of a large table. index scan of a large table.
However, LIMIT combined with ORDER BY often will use an index because 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() only a small portion of the table is returned.
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;
If you believe the optimizer is incorrect in choosing a sequential 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 scan, use SET enable_seqscan TO 'off' and run query again to see if an
index scan is indeed faster. index scan is indeed faster.
......
...@@ -10,7 +10,7 @@ ...@@ -10,7 +10,7 @@
alink="#0000ff"> alink="#0000ff">
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1> <H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
<P>Last updated: Sun Feb 12 12:15:49 EST 2006</P> <P>Last updated: Fri Feb 24 09:59:35 EST 2006</P>
<P>Current maintainer: Bruce Momjian (<A href= <P>Current maintainer: Bruce Momjian (<A href=
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>) "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)
...@@ -742,16 +742,8 @@ table?</TD><TD>unlimited</TD></TR> ...@@ -742,16 +742,8 @@ table?</TD><TD>unlimited</TD></TR>
usually faster than an index scan of a large table.</P> usually faster than an index scan of a large table.</P>
However, <SMALL>LIMIT</SMALL> combined with <SMALL>ORDER BY</SMALL> However, <SMALL>LIMIT</SMALL> combined with <SMALL>ORDER BY</SMALL>
often will use an index because only a small portion of the table 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, is returned.</P>
it is possible to retrieve such values using an index with ORDER BY
and LIMIT:
<PRE>
SELECT col
FROM tab
ORDER BY col [ DESC ]
LIMIT 1;
</PRE>
<P>If you believe the optimizer is incorrect in choosing a <P>If you believe the optimizer is incorrect in choosing a
sequential scan, use <CODE>SET enable_seqscan TO 'off'</CODE> and sequential scan, use <CODE>SET enable_seqscan TO 'off'</CODE> and
run query again to see if an index scan is indeed faster.</P> run query again to see if an index scan is indeed faster.</P>
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment