rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-30 12:51:22 +02:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Bruce Momjian 2006-02-24 14:59:54 +00:00
parent eb8f9cc066
commit 0915d370f5
2 changed files with 6 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/FAQ
View File

@ -1,7 +1,7 @@
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 @@
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.

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

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