Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
592caa08
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
592caa08
编写于
3月 03, 2002
作者:
B
Bruce Momjian
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update FAQ.
上级
343e47c2
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
73 addition
and
67 deletion
+73
-67
doc/FAQ
doc/FAQ
+22
-20
doc/src/FAQ/FAQ.html
doc/src/FAQ/FAQ.html
+51
-47
未找到文件。
doc/FAQ
浏览文件 @
592caa08
Frequently Asked Questions (FAQ) for PostgreSQL
Last updated:
Tue Feb 26 23:52:13
EST 2002
Last updated:
Sun Mar 3 11:02:16
EST 2002
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
...
...
@@ -706,28 +706,30 @@
4.8) My queries are slow or don't make use of the indexes. Why?
PostgreSQL does not automatically maintain statistics. VACUUM must be
run to update the statistics. After statistics are updated, the
optimizer knows how many rows in the table, and can better decide if
it should use indexes. Note that the optimizer does not use indexes in
cases when the table is small because a sequential scan would be
faster.
For column-specific optimization statistics, use VACUUM ANALYZE.
VACUUM ANALYZE is important for complex multijoin queries, so the
optimizer can estimate the number of rows returned from each table,
and choose the proper join order. The backend does not keep track of
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
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.
Indexes are not automatically used by every query. Indexes are only
used if the table is larger than a minimum size, and the index selects
only a small percentage of the rows in the table. This is because the
random disk access caused by an index scan is sometimes slower than a
straight read through the table, or sequential scan.
To determine if an index should be used, PostgreSQL must have
statistics about the table. These statistics are collected using
VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer
knows how many rows are in the table, and can better determine if
indexes should be used. Statistics are also valuable in determining
optimal join order and join methods. Statistics collection should be
performed periodically as the contents of the table change.
Indexes are normally not used for ORDER BY or to perform joins. A
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.
When using wild-card operators such as LIKE or ~, indexes can only be
used if the beginning of the search is anchored to the start of the
string.
So, to use indexes, LIKE searches should not begin with %, and
~(regular expression searches) should
start with ^.
string.
Therefore, to use indexes, LIKE patterns must not start with
%, and ~(regular expression) patterns must
start with ^.
4.9) How do I see how the query optimizer is evaluating my query?
...
...
doc/src/FAQ/FAQ.html
浏览文件 @
592caa08
...
...
@@ -14,7 +14,7 @@
alink=
"#0000ff"
>
<H1>
Frequently Asked Questions (FAQ) for PostgreSQL
</H1>
<P>
Last updated:
Tue Feb 26 23:52:13
EST 2002
</P>
<P>
Last updated:
Sun Mar 3 11:02:16
EST 2002
</P>
<P>
Current maintainer: Bruce Momjian (
<A
href=
"mailto:pgman@candle.pha.pa.us"
>
pgman@candle.pha.pa.us
</A>
)
<BR>
...
...
@@ -72,7 +72,8 @@
get
<I>
IpcMemoryCreate
</I>
errors. Why?
<BR>
<A
href=
"#3.4"
>
3.4
</A>
) When I try to start
<I>
postmaster
</I>
, I
get
<I>
IpcSemaphoreCreate
</I>
errors. Why?
<BR>
<A
href=
"#3.5"
>
3.5
</A>
) How do I control connections from other hosts?
<BR>
<A
href=
"#3.5"
>
3.5
</A>
) How do I control connections from other
hosts?
<BR>
<A
href=
"#3.6"
>
3.6
</A>
) How do I tune the database engine for
better performance?
<BR>
<A
href=
"#3.7"
>
3.7
</A>
) What debugging features are available?
<BR>
...
...
@@ -116,9 +117,9 @@
<SMALL>
SERIAL
</SMALL>
insert?
<BR>
<A
href=
"#4.15.3"
>
4.15.3
</A>
) Don't
<I>
currval()
</I>
and
<I>
nextval()
</I>
lead to a race condition with other users?
<BR>
<A
href=
"#4.15.4"
>
4.15.4
</A>
) Why aren't my sequence numbers
reused
on transaction abort? Why are there gaps in the numbering of my
sequence/SERIAL column?
<BR>
<A
href=
"#4.15.4"
>
4.15.4
</A>
) Why aren't my sequence numbers
reused on transaction abort? Why are there gaps in the numbering of
my
sequence/SERIAL column?
<BR>
<A
href=
"#4.16"
>
4.16
</A>
) What is an
<SMALL>
OID
</SMALL>
? What is a
<SMALL>
TID
</SMALL>
?
<BR>
<A
href=
"#4.17"
>
4.17
</A>
) What is the meaning of some of the terms
...
...
@@ -213,9 +214,9 @@
UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
</P>
<P>
The above is the BSD license, the classic open-source license.
It
has no restrictions on how the source code may be used. We like it
and have no intention of changing it.
</P>
<P>
The above is the BSD license, the classic open-source license.
It has no restrictions on how the source code may be used. We like
it
and have no intention of changing it.
</P>
<H4><A
name=
"1.3"
>
1.3
</A>
) What Unix platforms does PostgreSQL run
on?
</H4>
...
...
@@ -326,9 +327,11 @@
"http://www.PostgreSQL.org/docs/awbook.html"
>
http://www.PostgreSQL.org/docs/awbook.html
</A>
and
<A
href=
"http://www.commandprompt.com/ppbook/"
>
http://www.commandprompt.com/ppbook/
</A>
.
There is a list of PostgreSQL books available for purchase at
<A
href=
There is a list of PostgreSQL books available for purchase at
<A
href=
"http://www.postgresql.org/books/"
>
http://www.postgresql.org/books/
</A>
.
There is also a collection of PostgreSQL technical articles at
<A
href=
There is also a collection of PostgreSQL technical articles at
<A
href=
"http://techdocs.postgresql.org/"
>
http://techdocs.postgresql.org/
</A>
.
</P>
<P><I>
psql
</I>
has some nice \d commands to show information about
...
...
@@ -348,9 +351,9 @@
<P>
The PostgreSQL book at
<A
href=
"http://www.PostgreSQL.org/docs/awbook.html"
>
http://www.PostgreSQL.org/docs/awbook.html
</A>
teaches
<SMALL>
SQL
</SMALL>
. There is another PostgreSQL book at
<A
href=
"http://www.commandprompt.com/ppbook/"
>
http://www.commandprompt.com/ppbook.
</A>
teaches
<SMALL>
SQL
</SMALL>
. There is another PostgreSQL book at
<A
href=
"http://www.commandprompt.com/ppbook/"
>
http://www.commandprompt.com/ppbook.
</A>
There is a nice tutorial at
<A
href=
"http://www.intermedia.net/support/sql/sqltut.shtm"
>
http://www.intermedia.net/support/sql/sqltut.shtm,
</A>
at
<A
href=
...
...
@@ -856,14 +859,14 @@
<H4><A
name=
"4.6"
>
4.6
</A>
) How much database disk space is required
to store data from a typical text file?
</H4>
<P>
A PostgreSQL database may require up to five times the disk
space
to store data from a text file.
</P>
<P>
A PostgreSQL database may require up to five times the disk
space
to store data from a text file.
</P>
<P>
As an example, consider a file of 100,000 lines with an integer
and text description on each line. Suppose the text string
avergages
twenty bytes in length. The flat file would be 2.8 MB. The size
of the PostgreSQL database file containing this data can be
estimated as 6.4 MB:
</P>
and text description on each line. Suppose the text string
avergages twenty bytes in length. The flat file would be 2.8 MB.
The size of the PostgreSQL database file containing this data can
be
estimated as 6.4 MB:
</P>
<PRE>
36 bytes: each row header (approximate)
24 bytes: one int field and one text filed
...
...
@@ -899,33 +902,33 @@
<H4><A
name=
"4.8"
>
4.8
</A>
) My queries are slow or don't make use of
the indexes. Why?
</H4>
<P>
PostgreSQL does not automatically maintain statistics.
V
<SMALL>
ACUUM
</SMALL>
must be run to update the statistics. After
statistics are updated, the optimizer knows how many rows in the
table, and can better decide if it should use indexes. Note that
the optimizer does not use indexes in cases when the table is small
because a sequential scan would be faster.
</P>
<P>
For column-specific optimization statistics, use
<SMALL>
VACUUM
ANALYZE.
</SMALL>
V
<SMALL>
ACUUM ANALYZE
</SMALL>
is important for
complex multijoin queries, so the optimizer can estimate the number
of rows returned from each table, and choose the proper join order.
The backend does not keep track of column statistics on its own, so
<SMALL>
VACUUM ANALYZE
</SMALL>
must be run to collect them
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. This is because
random disk access is very slow.
</P>
Indexes are not automatically used by every query. Indexes are only
used if the table is larger than a minimum size, and the index
selects only a small percentage of the rows in the table. This is
because the random disk access caused by an index scan is sometimes
slower than a straight read through the table, or sequential scan.
<P>
To determine if an index should be used, PostgreSQL must have
statistics about the table. These statistics are collected using
<SMALL>
VACUUM ANALYZE
</SMALL>
, or simply
<SMALL>
ANALYZE
</SMALL>
.
Using statistics, the optimizer knows how many rows are in the
table, and can better determine if indexes should be used.
Statistics are also valuable in determining optimal join order and
join methods. Statistics collection should be performed
periodically as the contents of the table change.
</P>
<P>
Indexes are normally not used for
<SMALL>
ORDER BY
</SMALL>
or to
perform joins. A sequential scan followed by an explicit sort is
usually faster than an index scan of a large table.
</P>
However,
<SMALL>
LIMIT
</SMALL>
combined with
<SMALL>
ORDER BY
</SMALL>
often will use an index because only a small portion of the table
is returned.
<P>
When using wild-card operators such as
<SMALL>
LIKE
</SMALL>
or
<I>
~
</I>
, indexes can only be used if the beginning of the search
is anchored to the start of the string. So, to use indexes,
<SMALL>
LIKE
</SMALL>
searches should not begin with
<I>
%
</I>
, and
<I>
~
</I>
(regular expression searches) should start with
<I>
^
</I>
.
</P>
is anchored to the start of the string. Therefore, to use indexes,
<SMALL>
LIKE
</SMALL>
patterns must not start with
<I>
%
</I>
, and
<I>
~
</I>
(regular expression) patterns must start with
<I>
^
</I>
.
</P>
<H4><A
name=
"4.9"
>
4.9
</A>
) How do I see how the query optimizer is
evaluating my query?
</H4>
...
...
@@ -1091,13 +1094,14 @@ BYTEA bytea variable-length byte array (null-byte safe)
<P>
No. Currval() returns the current value assigned by your
backend, not by all users.
</P>
<H4><A
name=
"4.15.4"
>
4.15.4
</A>
) Why aren't my sequence numbers
reused
on transaction abort? Why are there gaps in the numbering of my
sequence/SERIAL column?
</H4>
<H4><A
name=
"4.15.4"
>
4.15.4
</A>
) Why aren't my sequence numbers
reused on transaction abort? Why are there gaps in the numbering of
my
sequence/SERIAL column?
</H4>
<P>
To improve concurrency, sequence values are given out to running
transactions as needed and are not locked until the transaction
completes. This causes gaps in numbering from aborted transactions.
completes. This causes gaps in numbering from aborted
transactions.
</P>
<H4><A
name=
"4.16"
>
4.16
</A>
) What is an
<SMALL>
OID
</SMALL>
? What is
a
<SMALL>
TID
</SMALL>
?
</H4>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录