I686LINUX/util/I686LINUX/doc/postgresql/html/performance-tips.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   2 <HTML
   3 ><HEAD
   4 ><TITLE
   5 >Performance Tips</TITLE
   6 ><META
   7 NAME="GENERATOR"
   8 CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
   9 REV="MADE"
  10 HREF="mailto:pgsql-docs@postgresql.org"><LINK
  11 REL="HOME"
  12 TITLE="PostgreSQL 7.4.1 Documentation"
  13 HREF="index.html"><LINK
  14 REL="UP"
  15 TITLE="The SQL Language"
  16 HREF="sql.html"><LINK
  17 REL="PREVIOUS"
  18 TITLE="Locking and Indexes"
  19 HREF="locking-indexes.html"><LINK
  20 REL="NEXT"
  21 TITLE="Statistics Used by the Planner"
  22 HREF="planner-stats.html"><LINK
  23 REL="STYLESHEET"
  24 TYPE="text/css"
  25 HREF="stylesheet.css"><META
  26 NAME="creation"
  27 CONTENT="2003-12-22T03:48:47"></HEAD
  28 ><BODY
  29 CLASS="CHAPTER"
  30 ><DIV
  31 CLASS="NAVHEADER"
  32 ><TABLE
  33 SUMMARY="Header navigation table"
  34 WIDTH="100%"
  35 BORDER="0"
  36 CELLPADDING="0"
  37 CELLSPACING="0"
  38 ><TR
  39 ><TH
  40 COLSPAN="5"
  41 ALIGN="center"
  42 VALIGN="bottom"
  43 >PostgreSQL 7.4.1 Documentation</TH
  44 ></TR
  45 ><TR
  46 ><TD
  47 WIDTH="10%"
  48 ALIGN="left"
  49 VALIGN="top"
  50 ><A
  51 HREF="locking-indexes.html"
  52 ACCESSKEY="P"
  53 >Prev</A
  54 ></TD
  55 ><TD
  56 WIDTH="10%"
  57 ALIGN="left"
  58 VALIGN="top"
  59 ><A
  60 HREF="mvcc.html"
  61 >Fast Backward</A
  62 ></TD
  63 ><TD
  64 WIDTH="60%"
  65 ALIGN="center"
  66 VALIGN="bottom"
  67 ></TD
  68 ><TD
  69 WIDTH="10%"
  70 ALIGN="right"
  71 VALIGN="top"
  72 ><A
  73 HREF="admin.html"
  74 >Fast Forward</A
  75 ></TD
  76 ><TD
  77 WIDTH="10%"
  78 ALIGN="right"
  79 VALIGN="top"
  80 ><A
  81 HREF="planner-stats.html"
  82 ACCESSKEY="N"
  83 >Next</A
  84 ></TD
  85 ></TR
  86 ></TABLE
  87 ><HR
  88 ALIGN="LEFT"
  89 WIDTH="100%"></DIV
  90 ><DIV
  91 CLASS="CHAPTER"
  92 ><H1
  93 ><A
  94 NAME="PERFORMANCE-TIPS"
  95 ></A
  96 >Chapter 13. Performance Tips</H1
  97 ><DIV
  98 CLASS="TOC"
  99 ><DL
 100 ><DT
 101 ><B
 102 >Table of Contents</B
 103 ></DT
 104 ><DT
 105 >13.1. <A
 106 HREF="performance-tips.html#USING-EXPLAIN"
 107 >Using <TT
 108 CLASS="COMMAND"
 109 >EXPLAIN</TT
 110 ></A
 111 ></DT
 112 ><DT
 113 >13.2. <A
 114 HREF="planner-stats.html"
 115 >Statistics Used by the Planner</A
 116 ></DT
 117 ><DT
 118 >13.3. <A
 119 HREF="explicit-joins.html"
 120 >Controlling the Planner with Explicit <TT
 121 CLASS="LITERAL"
 122 >JOIN</TT
 123 > Clauses</A
 124 ></DT
 125 ><DT
 126 >13.4. <A
 127 HREF="populate.html"
 128 >Populating a Database</A
 129 ></DT
 130 ><DD
 131 ><DL
 132 ><DT
 133 >13.4.1. <A
 134 HREF="populate.html#DISABLE-AUTOCOMMIT"
 135 >Disable Autocommit</A
 136 ></DT
 137 ><DT
 138 >13.4.2. <A
 139 HREF="populate.html#POPULATE-COPY-FROM"
 140 >Use <TT
 141 CLASS="COMMAND"
 142 >COPY FROM</TT
 143 ></A
 144 ></DT
 145 ><DT
 146 >13.4.3. <A
 147 HREF="populate.html#POPULATE-RM-INDEXES"
 148 >Remove Indexes</A
 149 ></DT
 150 ><DT
 151 >13.4.4. <A
 152 HREF="populate.html#POPULATE-SORT-MEM"
 153 >Increase <VAR
 154 CLASS="VARNAME"
 155 >sort_mem</VAR
 156 ></A
 157 ></DT
 158 ><DT
 159 >13.4.5. <A
 160 HREF="populate.html#POPULATE-ANALYZE"
 161 >Run <TT
 162 CLASS="COMMAND"
 163 >ANALYZE</TT
 164 > Afterwards</A
 165 ></DT
 166 ></DL
 167 ></DD
 168 ></DL
 169 ></DIV
 170 ><P
 171 >   Query performance can be affected by many things. Some of these can
 172    be manipulated by the user, while others are fundamental to the underlying
 173    design of the system.  This chapter provides some hints about understanding
 174    and tuning <SPAN
 175 CLASS="PRODUCTNAME"
 176 >PostgreSQL</SPAN
 177 > performance.
 178   </P
 179 ><DIV
 180 CLASS="SECT1"
 181 ><H1
 182 CLASS="SECT1"
 183 ><A
 184 NAME="USING-EXPLAIN"
 185 >13.1. Using <TT
 186 CLASS="COMMAND"
 187 >EXPLAIN</TT
 188 ></A
 189 ></H1
 190 ><A
 191 NAME="AEN13751"
 192 ></A
 193 ><A
 194 NAME="AEN13753"
 195 ></A
 196 ><P
 197 >    <SPAN
 198 CLASS="PRODUCTNAME"
 199 >PostgreSQL</SPAN
 200 > devises a <I
 201 CLASS="FIRSTTERM"
 202 >query
 203     plan</I
 204 > for each query it is given.  Choosing the right
 205     plan to match the query structure and the properties of the data
 206     is absolutely critical for good performance.  You can use the
 207     <TT
 208 CLASS="COMMAND"
 209 >EXPLAIN</TT
 210 > command to see what query plan the system
 211     creates for any query.
 212     Plan-reading is an art that deserves an extensive tutorial, which
 213     this is not; but here is some basic information.
 214    </P
 215 ><P
 216 >    The numbers that are currently quoted by <TT
 217 CLASS="COMMAND"
 218 >EXPLAIN</TT
 219 > are:
 220
 221     <P
 222 ></P
 223 ></P><UL
 224 ><LI
 225 ><P
 226 >       Estimated start-up cost (Time expended before output scan can start,
 227        e.g., time to do the sorting in a sort node.)
 228       </P
 229 ></LI
 230 ><LI
 231 ><P
 232 >       Estimated total cost (If all rows were to be retrieved, which they may not
 233        be: a query with a <TT
 234 CLASS="LITERAL"
 235 >LIMIT</TT
 236 > clause will stop short of paying the total cost,
 237        for example.)
 238       </P
 239 ></LI
 240 ><LI
 241 ><P
 242 >       Estimated number of rows output by this plan node (Again, only if
 243        executed to completion)
 244       </P
 245 ></LI
 246 ><LI
 247 ><P
 248 >       Estimated average width (in bytes) of rows output by this plan
 249        node
 250       </P
 251 ></LI
 252 ></UL
 253 ><P>
 254    </P
 255 ><P
 256 >    The costs are measured in units of disk page fetches.  (CPU effort
 257     estimates are converted into disk-page units using some
 258     fairly arbitrary fudge factors. If you want to experiment with these
 259     factors, see the list of run-time configuration parameters in
 260     <A
 261 HREF="runtime-config.html#RUNTIME-CONFIG-RESOURCE"
 262 >Section 16.4.2</A
 263 >.)
 264    </P
 265 ><P
 266 >    It's important to note that the cost of an upper-level node includes
 267     the cost of all its child nodes.  It's also important to realize that
 268     the cost only reflects things that the planner/optimizer cares about.
 269     In particular, the cost does not consider the time spent transmitting
 270     result rows to the frontend, which could be a pretty dominant
 271     factor in the true elapsed time; but the planner ignores it because
 272     it cannot change it by altering the plan.  (Every correct plan will
 273     output the same row set, we trust.)
 274    </P
 275 ><P
 276 >    Rows output is a little tricky because it is <SPAN
 277 CLASS="emphasis"
 278 ><I
 279 CLASS="EMPHASIS"
 280 >not</I
 281 ></SPAN
 282 > the
 283     number of rows
 284     processed/scanned by the query, it is usually less, reflecting the
 285     estimated selectivity of any <TT
 286 CLASS="LITERAL"
 287 >WHERE</TT
 288 >-clause conditions that are being
 289     applied at this node.  Ideally the top-level rows estimate will
 290     approximate the number of rows actually returned, updated, or deleted
 291     by the query.
 292    </P
 293 ><P
 294 >    Here are some examples (using the regression test database after a
 295     <TT
 296 CLASS="LITERAL"
 297 >VACUUM ANALYZE</TT
 298 >, and 7.3 development sources):
 299
 300 </P><PRE
 301 CLASS="PROGRAMLISTING"
 302 >EXPLAIN SELECT * FROM tenk1;
 303
 304                          QUERY PLAN
 305 -------------------------------------------------------------
 306  Seq Scan on tenk1  (cost=0.00..333.00 rows=10000 width=148)</PRE
 307 ><P>
 308    </P
 309 ><P
 310 >    This is about as straightforward as it gets.  If you do
 311
 312 </P><PRE
 313 CLASS="PROGRAMLISTING"
 314 >SELECT * FROM pg_class WHERE relname = 'tenk1';</PRE
 315 ><P>
 316
 317     you will find out that <CODE
 318 CLASS="CLASSNAME"
 319 >tenk1</CODE
 320 > has 233 disk
 321     pages and 10000 rows.  So the cost is estimated at 233 page
 322     reads, defined as costing 1.0 apiece, plus 10000 * <VAR
 323 CLASS="VARNAME"
 324 >cpu_tuple_cost</VAR
 325 > which is
 326     currently 0.01 (try <TT
 327 CLASS="COMMAND"
 328 >SHOW cpu_tuple_cost</TT
 329 >).
 330    </P
 331 ><P
 332 >    Now let's modify the query to add a <TT
 333 CLASS="LITERAL"
 334 >WHERE</TT
 335 > condition:
 336
 337 </P><PRE
 338 CLASS="PROGRAMLISTING"
 339 >EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 1000;
 340
 341                          QUERY PLAN
 342 ------------------------------------------------------------
 343  Seq Scan on tenk1  (cost=0.00..358.00 rows=1033 width=148)
 344    Filter: (unique1 &lt; 1000)</PRE
 345 ><P>
 346
 347     The estimate of output rows has gone down because of the <TT
 348 CLASS="LITERAL"
 349 >WHERE</TT
 350 > clause.
 351     However, the scan will still have to visit all 10000 rows, so the cost
 352     hasn't decreased; in fact it has gone up a bit to reflect the extra CPU
 353     time spent checking the <TT
 354 CLASS="LITERAL"
 355 >WHERE</TT
 356 > condition.
 357    </P
 358 ><P
 359 >    The actual number of rows this query would select is 1000, but the
 360     estimate is only approximate.  If you try to duplicate this experiment,
 361     you will probably get a slightly different estimate; moreover, it will
 362     change after each <TT
 363 CLASS="COMMAND"
 364 >ANALYZE</TT
 365 > command, because the
 366     statistics produced by <TT
 367 CLASS="COMMAND"
 368 >ANALYZE</TT
 369 > are taken from a
 370     randomized sample of the table.
 371    </P
 372 ><P
 373 >    Modify the query to restrict the condition even more:
 374
 375 </P><PRE
 376 CLASS="PROGRAMLISTING"
 377 >EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 50;
 378
 379                                    QUERY PLAN
 380 -------------------------------------------------------------------------------
 381  Index Scan using tenk1_unique1 on tenk1  (cost=0.00..179.33 rows=49 width=148)
 382    Index Cond: (unique1 &lt; 50)</PRE
 383 ><P>
 384
 385     and you will see that if we make the <TT
 386 CLASS="LITERAL"
 387 >WHERE</TT
 388 > condition selective
 389     enough, the planner will
 390     eventually decide that an index scan is cheaper than a sequential scan.
 391     This plan will only have to visit 50 rows because of the index,
 392     so it wins despite the fact that each individual fetch is more expensive
 393     than reading a whole disk page sequentially.
 394    </P
 395 ><P
 396 >    Add another condition to the <TT
 397 CLASS="LITERAL"
 398 >WHERE</TT
 399 > clause:
 400
 401 </P><PRE
 402 CLASS="PROGRAMLISTING"
 403 >EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 50 AND stringu1 = 'xxx';
 404
 405                                   QUERY PLAN
 406 -------------------------------------------------------------------------------
 407  Index Scan using tenk1_unique1 on tenk1  (cost=0.00..179.45 rows=1 width=148)
 408    Index Cond: (unique1 &lt; 50)
 409    Filter: (stringu1 = 'xxx'::name)</PRE
 410 ><P>
 411
 412     The added condition <TT
 413 CLASS="LITERAL"
 414 >stringu1 = 'xxx'</TT
 415 > reduces the
 416     output-rows estimate, but not the cost because we still have to visit the
 417     same set of rows.  Notice that the <TT
 418 CLASS="LITERAL"
 419 >stringu1</TT
 420 > clause
 421     cannot be applied as an index condition (since this index is only on
 422     the <TT
 423 CLASS="LITERAL"
 424 >unique1</TT
 425 > column).  Instead it is applied as a filter on
 426     the rows retrieved by the index.  Thus the cost has actually gone up
 427     a little bit to reflect this extra checking.
 428    </P
 429 ><P
 430 >    Let's try joining two tables, using the columns we have been discussing:
 431
 432 </P><PRE
 433 CLASS="PROGRAMLISTING"
 434 >EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 50 AND t1.unique2 = t2.unique2;
 435
 436                                QUERY PLAN
 437 ----------------------------------------------------------------------------
 438  Nested Loop  (cost=0.00..327.02 rows=49 width=296)
 439    -&gt;  Index Scan using tenk1_unique1 on tenk1 t1
 440                                       (cost=0.00..179.33 rows=49 width=148)
 441          Index Cond: (unique1 &lt; 50)
 442    -&gt;  Index Scan using tenk2_unique2 on tenk2 t2
 443                                       (cost=0.00..3.01 rows=1 width=148)
 444          Index Cond: ("outer".unique2 = t2.unique2)</PRE
 445 ><P>
 446    </P
 447 ><P
 448 >    In this nested-loop join, the outer scan is the same index scan we had
 449     in the example before last, and so its cost and row count are the same
 450     because we are applying the <TT
 451 CLASS="LITERAL"
 452 >WHERE</TT
 453 > clause <TT
 454 CLASS="LITERAL"
 455 >unique1 &lt; 50</TT
 456 > at that node.
 457     The <TT
 458 CLASS="LITERAL"
 459 >t1.unique2 = t2.unique2</TT
 460 > clause is not relevant yet, so it doesn't
 461     affect row count of the outer scan.  For the inner scan, the <TT
 462 CLASS="LITERAL"
 463 >unique2</TT
 464 > value of the
 465     current
 466     outer-scan row is plugged into the inner index scan
 467     to produce an index condition like
 468     <TT
 469 CLASS="LITERAL"
 470 >t2.unique2 = <VAR
 471 CLASS="REPLACEABLE"
 472 >constant</VAR
 473 ></TT
 474 >.  So we get the
 475      same inner-scan plan and costs that we'd get from, say, <TT
 476 CLASS="LITERAL"
 477 >EXPLAIN SELECT
 478      * FROM tenk2 WHERE unique2 = 42</TT
 479 >.  The costs of the loop node are then set
 480      on the basis of the cost of the outer scan, plus one repetition of the
 481      inner scan for each outer row (49 * 3.01, here), plus a little CPU
 482      time for join processing.
 483    </P
 484 ><P
 485 >    In this example the join's output row count is the same as the product
 486     of the two scans' row counts, but that's not true in general, because
 487     in general you can have <TT
 488 CLASS="LITERAL"
 489 >WHERE</TT
 490 > clauses that mention both tables and
 491     so can only be applied at the join point, not to either input scan.
 492     For example, if we added <TT
 493 CLASS="LITERAL"
 494 >WHERE ... AND t1.hundred &lt; t2.hundred</TT
 495 >,
 496     that would decrease the output row count of the join node, but not change
 497     either input scan.
 498    </P
 499 ><P
 500 >    One way to look at variant plans is to force the planner to disregard
 501     whatever strategy it thought was the winner, using the enable/disable
 502     flags for each plan type.  (This is a crude tool, but useful.  See
 503     also <A
 504 HREF="explicit-joins.html"
 505 >Section 13.3</A
 506 >.)
 507
 508 </P><PRE
 509 CLASS="PROGRAMLISTING"
 510 >SET enable_nestloop = off;
 511 EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 50 AND t1.unique2 = t2.unique2;
 512
 513                                QUERY PLAN
 514 --------------------------------------------------------------------------
 515  Hash Join  (cost=179.45..563.06 rows=49 width=296)
 516    Hash Cond: ("outer".unique2 = "inner".unique2)
 517    -&gt;  Seq Scan on tenk2 t2  (cost=0.00..333.00 rows=10000 width=148)
 518    -&gt;  Hash  (cost=179.33..179.33 rows=49 width=148)
 519          -&gt;  Index Scan using tenk1_unique1 on tenk1 t1
 520                                     (cost=0.00..179.33 rows=49 width=148)
 521                Index Cond: (unique1 &lt; 50)</PRE
 522 ><P>
 523
 524     This plan proposes to extract the 50 interesting rows of <CODE
 525 CLASS="CLASSNAME"
 526 >tenk1</CODE
 527 >
 528     using ye same olde index scan, stash them into an in-memory hash table,
 529     and then do a sequential scan of <CODE
 530 CLASS="CLASSNAME"
 531 >tenk2</CODE
 532 >, probing into the hash table
 533     for possible matches of <TT
 534 CLASS="LITERAL"
 535 >t1.unique2 = t2.unique2</TT
 536 > at each <CODE
 537 CLASS="CLASSNAME"
 538 >tenk2</CODE
 539 > row.
 540     The cost to read <CODE
 541 CLASS="CLASSNAME"
 542 >tenk1</CODE
 543 > and set up the hash table is entirely start-up
 544     cost for the hash join, since we won't get any rows out until we can
 545     start reading <CODE
 546 CLASS="CLASSNAME"
 547 >tenk2</CODE
 548 >.  The total time estimate for the join also
 549     includes a hefty charge for the CPU time to probe the hash table
 550     10000 times.  Note, however, that we are <SPAN
 551 CLASS="emphasis"
 552 ><I
 553 CLASS="EMPHASIS"
 554 >not</I
 555 ></SPAN
 556 > charging 10000 times 179.33;
 557     the hash table setup is only done once in this plan type.
 558    </P
 559 ><P
 560 >    It is possible to check on the accuracy of the planner's estimated costs
 561     by using <TT
 562 CLASS="COMMAND"
 563 >EXPLAIN ANALYZE</TT
 564 >.  This command actually executes the query,
 565     and then displays the true run time accumulated within each plan node
 566     along with the same estimated costs that a plain <TT
 567 CLASS="COMMAND"
 568 >EXPLAIN</TT
 569 > shows.
 570     For example, we might get a result like this:
 571
 572 </P><PRE
 573 CLASS="SCREEN"
 574 >EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 50 AND t1.unique2 = t2.unique2;
 575
 576                                    QUERY PLAN
 577 -------------------------------------------------------------------------------
 578  Nested Loop  (cost=0.00..327.02 rows=49 width=296)
 579                                  (actual time=1.181..29.822 rows=50 loops=1)
 580    -&gt;  Index Scan using tenk1_unique1 on tenk1 t1
 581                   (cost=0.00..179.33 rows=49 width=148)
 582                                  (actual time=0.630..8.917 rows=50 loops=1)
 583          Index Cond: (unique1 &lt; 50)
 584    -&gt;  Index Scan using tenk2_unique2 on tenk2 t2
 585                   (cost=0.00..3.01 rows=1 width=148)
 586                                  (actual time=0.295..0.324 rows=1 loops=50)
 587          Index Cond: ("outer".unique2 = t2.unique2)
 588  Total runtime: 31.604 ms</PRE
 589 ><P>
 590
 591     Note that the <SPAN
 592 CLASS="QUOTE"
 593 >"actual time"</SPAN
 594 > values are in milliseconds of
 595     real time, whereas the <SPAN
 596 CLASS="QUOTE"
 597 >"cost"</SPAN
 598 > estimates are expressed in
 599     arbitrary units of disk fetches; so they are unlikely to match up.
 600     The thing to pay attention to is the ratios.
 601    </P
 602 ><P
 603 >    In some query plans, it is possible for a subplan node to be executed more
 604     than once.  For example, the inner index scan is executed once per outer
 605     row in the above nested-loop plan.  In such cases, the
 606     <SPAN
 607 CLASS="QUOTE"
 608 >"loops"</SPAN
 609 > value reports the
 610     total number of executions of the node, and the actual time and rows
 611     values shown are averages per-execution.  This is done to make the numbers
 612     comparable with the way that the cost estimates are shown.  Multiply by
 613     the <SPAN
 614 CLASS="QUOTE"
 615 >"loops"</SPAN
 616 > value to get the total time actually spent in
 617     the node.
 618    </P
 619 ><P
 620 >    The <TT
 621 CLASS="LITERAL"
 622 >Total runtime</TT
 623 > shown by <TT
 624 CLASS="COMMAND"
 625 >EXPLAIN ANALYZE</TT
 626 > includes
 627     executor start-up and shut-down time, as well as time spent processing
 628     the result rows.  It does not include parsing, rewriting, or planning
 629     time.  For a <TT
 630 CLASS="COMMAND"
 631 >SELECT</TT
 632 > query, the total run time will normally be just a
 633     little larger than the total time reported for the top-level plan node.
 634     For <TT
 635 CLASS="COMMAND"
 636 >INSERT</TT
 637 >, <TT
 638 CLASS="COMMAND"
 639 >UPDATE</TT
 640 >, and <TT
 641 CLASS="COMMAND"
 642 >DELETE</TT
 643 > commands, the total run time may be
 644     considerably larger, because it includes the time spent processing the
 645     result rows.  In these commands, the time for the top plan node
 646     essentially is the time spent computing the new rows and/or locating
 647     the old ones, but it doesn't include the time spent making the changes.
 648    </P
 649 ><P
 650 >    It is worth noting that <TT
 651 CLASS="COMMAND"
 652 >EXPLAIN</TT
 653 > results should not be extrapolated
 654     to situations other than the one you are actually testing; for example,
 655     results on a toy-sized table can't be assumed to apply to large tables.
 656     The planner's cost estimates are not linear and so it may well choose
 657     a different plan for a larger or smaller table.  An extreme example
 658     is that on a table that only occupies one disk page, you'll nearly
 659     always get a sequential scan plan whether indexes are available or not.
 660     The planner realizes that it's going to take one disk page read to
 661     process the table in any case, so there's no value in expending additional
 662     page reads to look at an index.
 663    </P
 664 ></DIV
 665 ></DIV
 666 ><DIV
 667 CLASS="NAVFOOTER"
 668 ><HR
 669 ALIGN="LEFT"
 670 WIDTH="100%"><TABLE
 671 SUMMARY="Footer navigation table"
 672 WIDTH="100%"
 673 BORDER="0"
 674 CELLPADDING="0"
 675 CELLSPACING="0"
 676 ><TR
 677 ><TD
 678 WIDTH="33%"
 679 ALIGN="left"
 680 VALIGN="top"
 681 ><A
 682 HREF="locking-indexes.html"
 683 ACCESSKEY="P"
 684 >Prev</A
 685 ></TD
 686 ><TD
 687 WIDTH="34%"
 688 ALIGN="center"
 689 VALIGN="top"
 690 ><A
 691 HREF="index.html"
 692 ACCESSKEY="H"
 693 >Home</A
 694 ></TD
 695 ><TD
 696 WIDTH="33%"
 697 ALIGN="right"
 698 VALIGN="top"
 699 ><A
 700 HREF="planner-stats.html"
 701 ACCESSKEY="N"
 702 >Next</A
 703 ></TD
 704 ></TR
 705 ><TR
 706 ><TD
 707 WIDTH="33%"
 708 ALIGN="left"
 709 VALIGN="top"
 710 >Locking and Indexes</TD
 711 ><TD
 712 WIDTH="34%"
 713 ALIGN="center"
 714 VALIGN="top"
 715 ><A
 716 HREF="sql.html"
 717 ACCESSKEY="U"
 718 >Up</A
 719 ></TD
 720 ><TD
 721 WIDTH="33%"
 722 ALIGN="right"
 723 VALIGN="top"
 724 >Statistics Used by the Planner</TD
 725 ></TR
 726 ></TABLE
 727 ></DIV
 728 ></BODY
 729 ></HTML
 730 >