database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Add/edit index entries.

Browse Source
This commit is contained in:
Peter Eisentraut
2003-08-31 17:32:24 +00:00
parent cf8e916968
commit c326d8f4f2
162 changed files with 2653 additions and 1159 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
doc/src/sgml/perform.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.30 2003/06/25 02:07:33 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.31 2003/08/31 17:32:19 petere Exp $
-->
<chapter id="performance-tips">
@ -15,6 +15,14 @@ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.30 2003/06/25 02:07:33 mom
<sect1 id="using-explain">
<title>Using <command>EXPLAIN</command></title>
<indexterm zone="using-explain">
<primary>EXPLAIN</primary>
</indexterm>
<indexterm zone="using-explain">
<primary>query plan</primary>
</indexterm>
<para>
<productname>PostgreSQL</productname> devises a <firstterm>query
plan</firstterm> for each query it is given. Choosing the right
@ -336,6 +344,11 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 50 AND t1
<sect1 id="planner-stats">
<title>Statistics Used by the Planner</title>
<indexterm zone="planner-stats">
<primary>statistics</primary>
<secondary>of the planner</secondary>
</indexterm>
<para>
As we saw in the previous section, the query planner needs to estimate
the number of rows retrieved by a query in order to make good choices
@ -381,6 +394,10 @@ SELECT relname, relkind, reltuples, relpages FROM pg_class WHERE relname LIKE 't
since it does not read every row of the table.
</para>
<indexterm>
<primary>pg_statistic</primary>
</indexterm>
<para>
Most queries retrieve only a fraction of the rows in a table, due
to having <literal>WHERE</> clauses that restrict the rows to be examined.
@ -393,6 +410,10 @@ SELECT relname, relkind, reltuples, relpages FROM pg_class WHERE relname LIKE 't
and are always approximate even when freshly updated.
</para>
<indexterm>
<primary>pg_stats</primary>
</indexterm>
<para>
Rather than look at <structname>pg_statistic</structname> directly,
it's better to look at its view <structname>pg_stats</structname>
@ -538,6 +559,11 @@ SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'ro
<sect1 id="explicit-joins">
<title>Controlling the Planner with Explicit <literal>JOIN</> Clauses</title>
<indexterm zone="explicit-joins">
<primary>join</primary>
<secondary>controlling the order</secondary>
</indexterm>
<para>
It is possible
to control the query planner to some extent by using the explicit <literal>JOIN</>
@ -700,6 +726,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<sect2 id="disable-autocommit">
<title>Disable Autocommit</title>
<indexterm zone="disable-autocommit">
<primary>autocommit</primary>
</indexterm>
<para>
Turn off autocommit and just do one commit at
the end. (In plain SQL, this means issuing <command>BEGIN</command>