git.postgresql.org Git - postgresql.git/commitdiff

git projects / postgresql.git / commitdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: e07d894)
Update FAQ.
2001年5月30日 23:00:41 +0000 (23:00 +0000)
2001年5月30日 23:00:41 +0000 (23:00 +0000)

diff --git a/doc/FAQ b/doc/FAQ
index f59d74ff9a311274fb7d8b930f8d43073115d720..7224c15f7752590b792ffcf01abddc889c9ace14 100644 (file)
--- a/doc/FAQ
+++ b/doc/FAQ
@@ -1,7 +1,7 @@
Frequently Asked Questions (FAQ) for PostgreSQL
- Last updated: Wed May 30 18:57:52 EDT 2001
+ Last updated: Wed May 30 19:00:33 EDT 2001
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
@@ -709,9 +709,9 @@ Maximum number of indexes on a table? unlimited
column statistics on its own, so VACUUM ANALYZE must be run to collect
them periodically.
- Indexes are usually not used for ORDER BY or joins: a sequential scan
+ Indexes are usually not used for ORDER BY or joins. A sequential scan
followed by an explicit sort is faster than an indexscan of all tuples
- of a large table, because it takes fewer disk accesses.
+ of a large table. This is because random disk access is very slow.
When using wild-card operators such as LIKE or ~, indices can only be
used if the beginning of the search is anchored to the start of the
diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index 932b2b7856db3d4fa266bc214a043110ef56a79f..aba74b0e93ab1ff0754cc4067a197ee928fd7fdf 100644 (file)
--- a/doc/src/FAQ/FAQ.html
+++ b/doc/src/FAQ/FAQ.html
@@ -12,7 +12,7 @@
alink="#0000FF">
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
- <P>Last updated: Wed May 30 18:57:52 EDT 2001</P>
+ <P>Last updated: Wed May 30 19:00:33 EDT 2001</P>
<P>Current maintainer: Bruce Momjian (<A href=
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
@@ -908,9 +908,9 @@ Maximum number of indexes on a table? unlimited
periodically.</P>
<P>Indexes are usually not used for <SMALL>ORDER BY</SMALL>
- or joins: a sequential scan followed by an explicit sort is
- faster than an indexscan of all tuples of a large table, because it
- takes fewer disk accesses.</P>
+ or joins. A sequential scan followed by an explicit sort is
+ faster than an indexscan of all tuples of a large table. This
+ is because random disk access is very slow.</P>
<P>When using wild-card operators such as <SMALL>LIKE</SMALL> or
<I>~,</I> indices can only be used if the beginning of the search
This is the main PostgreSQL git repository.
RSS Atom

AltStyle によって変換されたページ (->オリジナル) /