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 of query plans. This section provides a quick look at the statistics that the system uses for these estimates. 前節で説明した通り、問い合わせプランナは、より良い問い合わせ計画を選択するために問い合わせによって取り出される行数の推定値を必要としています。 本節では、システムがこの推定に使用する統計情報について簡単に説明します。

One component of the statistics is the total number of entries in each table and index, as well as the number of disk blocks occupied by each table and index. This information is kept in the table <link linkend="catalog-pg-class"><structname>pg_class</structname></link>, in the columns <structfield>reltuples</structfield> and <structfield>relpages</structfield>. We can look at it with queries similar to this one: 統計情報の1つの構成要素は、各テーブルとインデックスの項目の総数と、各テーブルとインデックスが占めるディスクブロック数です。 この情報はpg_classのreltuplesとrelpages列に保持されます。 以下のような問い合わせによりこれを参照することができます。

SELECT relname, relkind, reltuples, relpages
FROM pg_class
WHERE relname LIKE 'tenk1%';

       relname        | relkind | reltuples | relpages
----------------------+---------+-----------+----------
 tenk1                | r       |     10000 |      358
 tenk1_hundred        | i       |     10000 |       30
 tenk1_thous_tenthous | i       |     10000 |       30
 tenk1_unique1        | i       |     10000 |       30
 tenk1_unique2        | i       |     10000 |       30
(5 rows)

Here we can see that <structname>tenk1</structname> contains 10000 rows, as do its indexes, but the indexes are (unsurprisingly) much smaller than the table. ここで、tenk1とそのインデックスには10000行が存在し、そして、（驚くには値しませんが）インデックスはテーブルよりもかなり小さなものであることがわかります。

For efficiency reasons, <structfield>reltuples</structfield> and <structfield>relpages</structfield> are not updated on-the-fly, and so they usually contain somewhat out-of-date values. They are updated by <command>VACUUM</command>, <command>ANALYZE</command>, and a few DDL commands such as <command>CREATE INDEX</command>. A <command>VACUUM</command> or <command>ANALYZE</command> operation that does not scan the entire table (which is commonly the case) will incrementally update the <structfield>reltuples</structfield> count on the basis of the part of the table it did scan, resulting in an approximate value. In any case, the planner will scale the values it finds in <structname>pg_class</structname> to match the current physical table size, thus obtaining a closer approximation. 効率を上げるため、reltuplesとrelpagesは処理の度には更新されず、したがって通常は多少古い値のみ所有しています。 これらはVACUUM、ANALYZE、CREATE INDEXなどの一部のDDLコマンドによって更新されます。 テーブル全体をスキャンしないVACUUM、ANALYZE操作（一般的な状況です）は、スキャンされたテーブルの部分に基づいてreltuples値を漸次更新し、概算値を生成します。 いずれの場合でもプランナは、現在の物理的なテーブルサイズに合わせるためにpg_classから検索した値を調整して、より高精度な近似値を得ます。

Most queries retrieve only a fraction of the rows in a table, due to <literal>WHERE</literal> clauses that restrict the rows to be examined. The planner thus needs to make an estimate of the <firstterm>selectivity</firstterm> of <literal>WHERE</literal> clauses, that is, the fraction of rows that match each condition in the <literal>WHERE</literal> clause. The information used for this task is stored in the <link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link> system catalog. Entries in <structname>pg_statistic</structname> are updated by the <command>ANALYZE</command> and <command>VACUUM ANALYZE</command> commands, and are always approximate even when freshly updated. ほとんどの問い合わせは、検証される行を制限するWHERE句によって、テーブル内の行の一部のみを取り出します。 したがって、プランナはWHERE句の選択性、つまりWHERE句の各条件にどれだけの行が一致するかを推定する必要があります。 この処理に使用される情報はpg_statisticシステムカタログ内に格納されます。 pg_statistic内の項目は、ANALYZEとVACUUM ANALYZEコマンドによって更新され、また１から更新がかかったとしても常に概算値になります。

Rather than look at <structname>pg_statistic</structname> directly, it's better to look at its view <link linkend="view-pg-stats"><structname>pg_stats</structname></link> when examining the statistics manually. <structname>pg_stats</structname> is designed to be more easily readable. Furthermore, <structname>pg_stats</structname> is readable by all, whereas <structname>pg_statistic</structname> is only readable by a superuser. (This prevents unprivileged users from learning something about the contents of other people's tables from the statistics. The <structname>pg_stats</structname> view is restricted to show only rows about tables that the current user can read.) For example, we might do: 統計情報を手作業で確認する場合、pg_statisticを直接参照するのではなく、pg_statsビューを参照する方が良いでしょう。 pg_statsはより読みやすくなるように設計されています。 さらに、pg_statsは誰でも読み取ることができますが、pg_statisticはスーパーユーザのみ読み取ることができます。 （これは、非特権ユーザが統計情報から他人のテーブルの内容に関わる事項を読み取ることを防止します。 pg_statsビューは現在のユーザが読み取ることができるテーブルに関する行のみを表示するよう制限されています。） 例えば、以下を行うことができます。

SELECT attname, inherited, n_distinct,
       array_to_string(most_common_vals, E'\n') as most_common_vals
FROM pg_stats
WHERE tablename = 'road';

 attname | inherited | n_distinct |          most_common_vals
---------+-----------+------------+------------------------------------
 name    | f         |  -0.363388 | I- 580                        Ramp+
         |           |            | I- 880                        Ramp+
         |           |            | Sp Railroad                       +
         |           |            | I- 580                            +
         |           |            | I- 680                        Ramp
 name    | t         |  -0.284859 | I- 880                        Ramp+
         |           |            | I- 580                        Ramp+
         |           |            | I- 680                        Ramp+
         |           |            | I- 580                            +
         |           |            | State Hwy 13                  Ramp
(2 rows)

Note that two rows are displayed for the same column, one corresponding to the complete inheritance hierarchy starting at the <literal>road</literal> table (<literal>inherited</literal>=<literal>t</literal>), and another one including only the <literal>road</literal> table itself (<literal>inherited</literal>=<literal>f</literal>). 同じ列に対して2行が表示されていることに注意してください。 1つはroadテーブルが始まる継承階層(inherited=t)全体に相当し、もう1つはroadテーブル自身(inherited=f)のみを含むものです。

The amount of information stored in <structname>pg_statistic</structname> by <command>ANALYZE</command>, in particular the maximum number of entries in the <structfield>most_common_vals</structfield> and <structfield>histogram_bounds</structfield> arrays for each column, can be set on a column-by-column basis using the <command>ALTER TABLE SET STATISTICS</command> command, or globally by setting the <xref linkend="guc-default-statistics-target"/> configuration variable. The default limit is presently 100 entries. Raising the limit might allow more accurate planner estimates to be made, particularly for columns with irregular data distributions, at the price of consuming more space in <structname>pg_statistic</structname> and slightly more time to compute the estimates. Conversely, a lower limit might be sufficient for columns with simple data distributions. ANALYZEによりpg_statisticに格納される情報量、具体的には、それぞれの列に対するmost_common_vals内とhistogram_bounds配列のエントリの最大数は、ALTER TABLE SET STATISTICSコマンドによって列ごとに、default_statistics_target設定パラメータを設定することによってグローバルに設定することができます。 現在のデフォルトの上限は100エントリです。 この上限を上げることで、特に、少し変わったデータ分布を持つ列でより正確なプランナの推定が行われますが、pg_statisticにより多くの容量が必要になり、多少推定計算にかかる時間が多くなります。 反対に上限を下げることは、単純なデータ分布の列に対して順当です。

Further details about the planner's use of statistics can be found in <xref linkend="planner-stats-details"/>. プランナによる統計情報の使用に関する詳細については第76章を参照してください。

It is common to see slow queries running bad execution plans because multiple columns used in the query clauses are correlated. The planner normally assumes that multiple conditions are independent of each other, an assumption that does not hold when column values are correlated. Regular statistics, because of their per-individual-column nature, cannot capture any knowledge about cross-column correlation. However, <productname>PostgreSQL</productname> has the ability to compute <firstterm>multivariate statistics</firstterm>, which can capture such information. 問い合わせ句で使われている複数列に相関性があることにより、悪い実行計画を実行する遅いクエリがしばしば観察されます。 プランナは通常複数の条件がお互いに独立であるとみなしますが、列の値に相関性がある場合はそれは成り立ちません。 通常の列ごとの統計情報は、それが個々の列ごとであるという性質上、列をまたがる相関性に関する知識を把握することはできません。 しかしながら、PostgreSQLは、多変量統計情報を計算することができ、それによってそうした情報を把握することができます。

Because the number of possible column combinations is very large, it's impractical to compute multivariate statistics automatically. Instead, <firstterm>extended statistics objects</firstterm>, more often called just <firstterm>statistics objects</firstterm>, can be created to instruct the server to obtain statistics across interesting sets of columns. 列の組み合わせの数は非常に大きいため、自動的に多変量統計情報を計算するのは現実的ではありません。 代わりに、サーバが興味のある列の集合にまたがる統計情報を得るように指示する目的で、拡張統計情報オブジェクト（しばしば単に統計情報オブジェクトと呼ばれます）を作成することができます。

Statistics objects are created using the <link linkend="sql-createstatistics"><command>CREATE STATISTICS</command></link> command. Creation of such an object merely creates a catalog entry expressing interest in the statistics. Actual data collection is performed by <command>ANALYZE</command> (either a manual command, or background auto-analyze). The collected values can be examined in the <link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link> catalog. 統計情報オブジェクトはCREATE STATISTICSで作成します。 そうしたオブジェクトを作っても、単に統計情報として興味があることを示すカタログエントリが作られるだけです。 実際のデータ収集は、ANALYZE （手動のコマンドを起動あるいはバックグラウンドでの自動ANALYZE）が行います。 収集したデータは、pg_statistic_ext_dataカタログで参照することができます。

<command>ANALYZE</command> computes extended statistics based on the same sample of table rows that it takes for computing regular single-column statistics. Since the sample size is increased by increasing the statistics target for the table or any of its columns (as described in the previous section), a larger statistics target will normally result in more accurate extended statistics, as well as more time spent calculating them. 通常の単一列統計情報の計算に使うのと同じテーブル行のサンプルに基づき、ANALYZEは、拡張統計情報を計算します。 （前節で述べたように）テーブルあるいはそのテーブルの対象となる列統計情報の増やすと、サンプルのサイズも増えるので、より大きな統計情報の対象を使うと、通常、より精度の高い拡張統計情報を得られますが、計算に費やす時間も増えます。

The following subsections describe the kinds of extended statistics that are currently supported. 次の節では、現在サポートしている拡張統計情報の種類を説明します。

CREATE STATISTICS stts (dependencies) ON city, zip FROM zipcodes;

ANALYZE zipcodes;

SELECT stxname, stxkeys, stxddependencies
  FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid)
  WHERE stxname = 'stts';
 stxname | stxkeys |             stxddependencies
---------+---------+------------------------------------------
 stts    | 1 5     | {"1 => 5": 1.000000, "5 => 1": 0.423130}
(1 row)

SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '94105';

SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '90210';

CREATE STATISTICS stts2 (ndistinct) ON city, state, zip FROM zipcodes;

ANALYZE zipcodes;

SELECT stxkeys AS k, stxdndistinct AS nd
  FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid)
  WHERE stxname = 'stts2';
-[ RECORD 1 ]------------------------------------------------------​--
k  | 1 2 5
nd | {"1, 2": 33178, "1, 5": 33178, "2, 5": 27435, "1, 2, 5": 33178}
(1 row)

CREATE STATISTICS stts3 (mcv) ON city, state FROM zipcodes;

ANALYZE zipcodes;

SELECT m.* FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid),
                pg_mcv_list_items(stxdmcv) m WHERE stxname = 'stts3';

 index |         values         | nulls | frequency | base_frequency
-------+------------------------+-------+-----------+----------------
     0 | {Washington, DC}       | {f,f} |  0.003467 |        2.7e-05
     1 | {Apo, AE}              | {f,f} |  0.003067 |        1.9e-05
     2 | {Houston, TX}          | {f,f} |  0.002167 |       0.000133
     3 | {El Paso, TX}          | {f,f} |     0.002 |       0.000113
     4 | {New York, NY}         | {f,f} |  0.001967 |       0.000114
     5 | {Atlanta, GA}          | {f,f} |  0.001633 |        3.3e-05
     6 | {Sacramento, CA}       | {f,f} |  0.001433 |        7.8e-05
     7 | {Miami, FL}            | {f,f} |    0.0014 |          6e-05
     8 | {Dallas, TX}           | {f,f} |  0.001367 |        8.8e-05
     9 | {Chicago, IL}          | {f,f} |  0.001333 |        5.1e-05
   ...
(99 rows)