← Back to branch summary

~ubuntu-branches/ubuntu/lucid/postgresql-8.4/lucid-proposed

« back to all changes in this revision

Viewing changes to doc/src/sgml/perform.sgml

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2009-07-11 16:59:35 UTC
  • mfrom: (5.1.1 karmic)
  • Revision ID: james.westby@ubuntu.com-20090711165935-jfwin6gfrxf0gfsi
Tags: 8.4.0-2
http://bugs.debian.org/536139
* debian/libpq-dev.install: Ship catalog/genbki.h. (Closes: #536139)
* debian/rules: Drop --enable-cassert for final release.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/perform.sgml
1
 
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.70 2009/04/27 16:27:36 momjian Exp $ -->
 
1
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.71 2009/06/17 21:58:49 tgl Exp $ -->
2
2
 
3
3
 <chapter id="performance-tips">
4
4
  <title>Performance Tips</title>
45
45
    table access methods: sequential scans, index scans, and bitmap index
46
46
    scans.  If the query requires joining, aggregation, sorting, or other
47
47
    operations on the raw rows, then there will be additional nodes
48
 
    above the scan nodes to perform these operations.  Other nodes types
49
 
    are also supported.  The output
 
48
    above the scan nodes to perform these operations.  Again,
 
49
    there is usually more than one possible way to do these operations,
 
50
    so different node types can appear here too.  The output
50
51
    of <command>EXPLAIN</command> has one line for each node in the plan
51
52
    tree, showing the basic node type plus the cost estimates that the planner
52
53
    made for the execution of that plan node.  The first line (topmost node)
83
84
    <itemizedlist>
84
85
     <listitem>
85
86
      <para>
86
 
       Estimated start-up cost, e.g., time expended before the output scan can start,
87
 
       time to do the sorting in a sort node
 
87
       Estimated start-up cost (time expended before the output scan can start,
 
88
       e.g., time to do the sorting in a sort node)
88
89
      </para>
89
90
     </listitem>
90
91
 
91
92
     <listitem>
92
93
      <para>
93
 
       Estimated total cost if all rows were to be retrieved (though they might
94
 
       not be, e.g., a query with a <literal>LIMIT</> clause will stop
95
 
       short of paying the total cost of the <literal>Limit</> node's
 
94
       Estimated total cost (if all rows are retrieved, though they might
 
95
       not be; e.g., a query with a <literal>LIMIT</> clause will stop
 
96
       short of paying the total cost of the <literal>Limit</> plan node's
96
97
       input node)
97
98
      </para>
98
99
     </listitem>
99
100
 
100
101
     <listitem>
101
102
      <para>
102
 
       Estimated number of rows output by this plan node (Again, only if
103
 
       executed to completion.)
 
103
       Estimated number of rows output by this plan node (again, only if
 
104
       executed to completion)
104
105
      </para>
105
106
     </listitem>
106
107
 
129
130
    the cost only reflects things that the planner cares about.
130
131
    In particular, the cost does not consider the time spent transmitting
131
132
    result rows to the client, which could be an important
132
 
    factor in the total elapsed time; but the planner ignores it because
 
133
    factor in the real elapsed time; but the planner ignores it because
133
134
    it cannot change it by altering the plan.  (Every correct plan will
134
135
    output the same row set, we trust.)
135
136
   </para>
136
137
 
137
138
   <para>
138
 
    The <command>EXPLAIN</command> <literal>rows=</> value is a little tricky
 
139
    The <literal>rows</> value is a little tricky
139
140
    because it is <emphasis>not</emphasis> the
140
141
    number of rows processed or scanned by the plan node.  It is usually less,
141
142
    reflecting the estimated selectivity of any <literal>WHERE</>-clause
142
143
    conditions that are being
143
 
    applied to the node.  Ideally the top-level rows estimate will
 
144
    applied at the node.  Ideally the top-level rows estimate will
144
145
    approximate the number of rows actually returned, updated, or deleted
145
146
    by the query.
146
147
   </para>
197
198
   </para>
198
199
 
199
200
   <para>
200
 
    The actual number of rows this query would select is 7000, but the <literal>rows=</>
 
201
    The actual number of rows this query would select is 7000, but the <literal>rows</>
201
202
    estimate is only approximate.  If you try to duplicate this experiment,
202
203
    you will probably get a slightly different estimate; moreover, it will
203
204
    change after each <command>ANALYZE</command> command, because the
234
235
 
235
236
   <para>
236
237
    If the <literal>WHERE</> condition is selective enough, the planner might
237
 
    switch to a <emphasis>simple</> index scan plan:
 
238
    switch to a <quote>simple</> index scan plan:
238
239
 
239
240
<programlisting>
240
241
EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 3;
248
249
    In this case the table rows are fetched in index order, which makes them
249
250
    even more expensive to read, but there are so few that the extra cost
250
251
    of sorting the row locations is not worth it.  You'll most often see
251
 
    this plan type in queries that fetch just a single row, and for queries
252
 
    with an <literal>ORDER BY</> condition that matches the index
 
252
    this plan type for queries that fetch just a single row, and for queries
 
253
    that have an <literal>ORDER BY</> condition that matches the index
253
254
    order.
254
255
   </para>
255
256
 
320
321
   </para>
321
322
 
322
323
   <para>
323
 
    In this nested-loop join, the outer scan (upper) is the same bitmap index scan we
 
324
    In this nested-loop join, the outer (upper) scan is the same bitmap index scan we
324
325
    saw earlier, and so its cost and row count are the same because we are
325
326
    applying the <literal>WHERE</> clause <literal>unique1 &lt; 100</literal>
326
327
    at that node.
409
410
</screen>
410
411
 
411
412
    Note that the <quote>actual time</quote> values are in milliseconds of
412
 
    real time, whereas the <literal>cost=</> estimates are expressed in
 
413
    real time, whereas the <literal>cost</> estimates are expressed in
413
414
    arbitrary units; so they are unlikely to match up.
414
415
    The thing to pay attention to is whether the ratios of actual time and
415
416
    estimated costs are consistent.
419
420
    In some query plans, it is possible for a subplan node to be executed more
420
421
    than once.  For example, the inner index scan is executed once per outer
421
422
    row in the above nested-loop plan.  In such cases, the
422
 
    <literal>loops=</> value reports the
 
423
    <literal>loops</> value reports the
423
424
    total number of executions of the node, and the actual time and rows
424
425
    values shown are averages per-execution.  This is done to make the numbers
425
426
    comparable with the way that the cost estimates are shown.  Multiply by
426
 
    the <literal>loops=</> value to get the total time actually spent in
 
427
    the <literal>loops</> value to get the total time actually spent in
427
428
    the node.
428
429
   </para>
429
430
 
780
781
   </indexterm>
781
782
 
782
783
   <para>
783
 
    When doing <command>INSERT</>s, turn off autocommit and just do
 
784
    When using multiple <command>INSERT</>s, turn off autocommit and just do
784
785
    one commit at the end.  (In plain
785
786
    SQL, this means issuing <command>BEGIN</command> at the start and
786
787
    <command>COMMIT</command> at the end.  Some client libraries might
824
825
   <para>
825
826
    Note that loading a large number of rows using
826
827
    <command>COPY</command> is almost always faster than using
827
 
    <command>INSERT</command>, even if the <command>PREPARE ... INSERT</> is used and
 
828
    <command>INSERT</command>, even if <command>PREPARE</> is used and
828
829
    multiple insertions are batched into a single transaction.
829
830
   </para>
830
831