|
1 | 1 | <!--
|
2 |
| -$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.42 2004/03/09 16:57:46 neilc Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.43 2004/03/25 18:57:57 tgl Exp $ |
3 | 3 | -->
|
4 | 4 |
|
5 | 5 | <chapter id="performance-tips">
|
@@ -120,7 +120,8 @@ SELECT * FROM pg_class WHERE relname = 'tenk1';
|
120 | 120 |
|
121 | 121 | you will find out that <classname>tenk1</classname> has 233 disk
|
122 | 122 | pages and 10000 rows. So the cost is estimated at 233 page
|
123 |
| - reads, defined as costing 1.0 apiece, plus 10000 * <varname>cpu_tuple_cost</varname> which is |
| 123 | + reads, defined as costing 1.0 apiece, plus 10000 * <xref |
| 124 | + linkend="guc-cpu-tuple-cost"> which is |
124 | 125 | currently 0.01 (try <command>SHOW cpu_tuple_cost</command>).
|
125 | 126 | </para>
|
126 | 127 |
|
@@ -450,7 +451,7 @@ SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'ro
|
450 | 451 | arrays for each column, can be set on a
|
451 | 452 | column-by-column basis using the <command>ALTER TABLE SET STATISTICS</>
|
452 | 453 | command, or globally by setting the
|
453 |
| - <varname>default_statistics_target</varname> runtime parameter. |
| 454 | + <xref linkend="guc-default-statistics-target"> configuration variable. |
454 | 455 | The default limit is presently 10 entries. Raising the limit
|
455 | 456 | may allow more accurate planner estimates to be made, particularly for
|
456 | 457 | columns with irregular data distributions, at the price of consuming
|
@@ -599,14 +600,15 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
|
599 | 600 | problem replacing two separate three-way join problems. Because of the
|
600 | 601 | exponential growth of the number of possibilities, this makes a big
|
601 | 602 | difference. The planner tries to avoid getting stuck in huge join search
|
602 |
| - problems by not collapsing a subquery if more than <xref linkend="guc-from-collapse-limit"> |
| 603 | + problems by not collapsing a subquery if more than <varname>from_collapse_limit</> |
603 | 604 | <literal>FROM</> items would result in the parent
|
604 | 605 | query. You can trade off planning time against quality of plan by
|
605 | 606 | adjusting this run-time parameter up or down.
|
606 | 607 | </para>
|
607 | 608 |
|
608 | 609 | <para>
|
609 |
| - <varname>from_collapse_limit</> and <varname>join_collapse_limit</> |
| 610 | + <xref linkend="guc-from-collapse-limit"> and <xref |
| 611 | + linkend="guc-join-collapse-limit"> |
610 | 612 | are similarly named because they do almost the same thing: one controls
|
611 | 613 | when the planner will <quote>flatten out</> subselects, and the
|
612 | 614 | other controls when it will flatten out explicit inner joins. Typically
|
|
0 commit comments