説明

<command>CREATE STATISTICS</command> will create a new extended statistics object tracking data about the specified table, foreign table or materialized view. The statistics object will be created in the current database and will be owned by the user issuing the command. CREATE STATISTICSは指定したテーブル、外部テーブル、マテリアライズドビューのデータを追跡する新しい拡張統計オブジェクトを作成します。 統計オブジェクトは現在のデータベースに作成され、コマンドを実行したユーザに所有されます。

The <command>CREATE STATISTICS</command> command has two basic forms. The first form allows univariate statistics for a single expression to be collected, providing benefits similar to an expression index without the overhead of index maintenance. This form does not allow the statistics kind to be specified, since the various statistics kinds refer only to multivariate statistics. The second form of the command allows multivariate statistics on multiple columns and/or expressions to be collected, optionally specifying which statistics kinds to include. This form will also automatically cause univariate statistics to be collected on any expressions included in the list. CREATE STATISTICSコマンドには2つの基本的な形式があります。 1つ目の形式では、1つの式に対して単変量統計を集めることができ、式インデックスと同様の利点をインデックスの保守のオーバーヘッドを伴わずに提供します。 様々な統計の種別は多変量統計だけに関連しますので、この形式では統計の種別を指定できません。 コマンドの2つ目の形式では、複数の列や式の多変量統計を集めることができ、含まれる統計の種別もオプションで指定できます。 この形式では、自動的にリストに含まれる式の単変量統計も集められます。

If a schema name is given (for example, <literal>CREATE STATISTICS myschema.mystat ...</literal>) then the statistics object is created in the specified schema. Otherwise it is created in the current schema. If given, the name of the statistics object must be distinct from the name of any other statistics object in the same schema. スキーマ名が指定された場合（例：CREATE STATISTICS myschema.mystat ...）、統計オブジェクトは指定したスキーマ内に作成されます。 スキーマ名を指定しなければ、現在のスキーマ内に作成されます。 統計オブジェクトの名前を指定する場合は、同じスキーマ内のどの統計オブジェクトとも異なるものでなければなりません。

パラメータ

注釈

You must be the owner of a table to create a statistics object reading it. Once created, however, the ownership of the statistics object is independent of the underlying table(s). テーブルを読み取る統計オブジェクトを作るには、そのテーブルの所有者でなければなりません。 しかし、統計オブジェクトが作成された後は、その所有者と対象となるテーブルは無関係になります。

Expression statistics are per-expression and are similar to creating an index on the expression, except that they avoid the overhead of index maintenance. Expression statistics are built automatically for each expression in the statistics object definition. 式統計は式ごとのものであり、インデックスの保守のオーバーヘッドを避けられるということ以外は式にインデックスを作るのと似ています。 式統計は、統計オブジェクト定義内の各式に対して自動的に構築されます。

Extended statistics are not currently used by the planner for selectivity estimations made for table joins. This limitation will likely be removed in a future version of <productname>PostgreSQL</productname>. 拡張統計処理は現在、プランナによってテーブル結合に対して行なわれる選択性の見積もりには使用されていません。 この制限は、PostgreSQLの将来のバージョンで削除される可能性があります。

例

Create table <structname>t1</structname> with two functionally dependent columns, i.e., knowledge of a value in the first column is sufficient for determining the value in the other column. Then functional dependency statistics are built on those columns: 関数従属性のある2つの列を含むテーブルt1を作成します。 つまり、第1の列の値を知っていれば、それだけでもう一方の列の値がわかる、というものです。 その次に、これらの列の間に関数的依存統計を構築します。

CREATE TABLE t1 (
    a   int,
    b   int
);

INSERT INTO t1 SELECT i/100, i/500
                 FROM generate_series(1,1000000) s(i);

ANALYZE t1;


-- the number of matching rows will be drastically underestimated:

-- マッチする行の数は非常に低く見積もられる
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

CREATE STATISTICS s1 (dependencies) ON a, b FROM t1;

ANALYZE t1;


-- now the row count estimate is more accurate:

-- 行数の見積もりがより正確になる
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

Without functional-dependency statistics, the planner would assume that the two <literal>WHERE</literal> conditions are independent, and would multiply their selectivities together to arrive at a much-too-small row count estimate. With such statistics, the planner recognizes that the <literal>WHERE</literal> conditions are redundant and does not underestimate the row count. 関数的依存統計がなければ、プランナは2つのWHERE条件を独立なものとみなすため、それらの選択性を掛け算して、非常に小さな行数見積もりを導きます。 このような統計があれば、プランナはWHERE条件が冗長であることを認識し、行数を低く見積もりません。

Create table <structname>t2</structname> with two perfectly correlated columns (containing identical data), and an MCV list on those columns: (同一のデータの入った)完全に相関のある2つの列を持つテーブルt2を作成し、2つの列の最頻値(MCV)の一覧を作成します。

CREATE TABLE t2 (
    a   int,
    b   int
);

INSERT INTO t2 SELECT mod(i,100), mod(i,100)
                 FROM generate_series(1,1000000) s(i);

CREATE STATISTICS s2 (mcv) ON a, b FROM t2;

ANALYZE t2;


-- valid combination (found in MCV)

-- 有効な組み合わせ(MCV内で見つかる)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 1);


-- invalid combination (not found in MCV)

-- 無効な組み合わせ(MCV内で見つからない)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 2);

The MCV list gives the planner more detailed information about the specific values that commonly appear in the table, as well as an upper bound on the selectivities of combinations of values that do not appear in the table, allowing it to generate better estimates in both cases. 最頻値の一覧は、テーブルによく現れる特定の値に関するものだけでなく、テーブルに現れない値の組み合わせの選択の上限に関するより詳細な情報もプランナに与えますので、両方の場合に対してより良く見積もりができるようになります。

Create table <structname>t3</structname> with a single timestamp column, and run queries using expressions on that column. Without extended statistics, the planner has no information about the data distribution for the expressions, and uses default estimates. The planner also does not realize that the value of the date truncated to the month is fully determined by the value of the date truncated to the day. Then expression and ndistinct statistics are built on those two expressions: タイムスタンプの列1つのテーブルt3を作成し、その列の式を使う問い合わせを実行します。 拡張統計なしでは、プランナはその式に対するデータ分布についての情報がなく、デフォルトの評価を使います。 プランナは、月で切り捨てられた日付の値は日にちで切り捨てられた日付の値により完全に決められることにも気付きません。 それから、この2つの式に対して、式統計とN個別値統計を構築します。

CREATE TABLE t3 (
    a   timestamp
);

INSERT INTO t3 SELECT i FROM generate_series('2020-01-01'::timestamp,
                                             '2020-12-31'::timestamp,
                                             '1 minute'::interval) s(i);

ANALYZE t3;


-- the number of matching rows will be drastically underestimated:

-- マッチする行数は大幅に過小評価されます。
EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc('month', a) = '2020-01-01'::timestamp;

EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc('day', a) BETWEEN '2020-01-01'::timestamp
                                 AND '2020-06-30'::timestamp;

EXPLAIN ANALYZE SELECT date_trunc('month', a), date_trunc('day', a)
   FROM t3 GROUP BY 1, 2;


-- build ndistinct statistics on the pair of expressions (per-expression
-- statistics are built automatically)

-- 式の組み合わせに対してN個別値統計を構築します
-- (式ごとの統計は自動的に構築されます)
CREATE STATISTICS s3 (ndistinct) ON date_trunc('month', a), date_trunc('day', a) FROM t3;

ANALYZE t3;


-- now the row count estimates are more accurate:

-- 行数の評価はより正確になります。
EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc('month', a) = '2020-01-01'::timestamp;

EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc('day', a) BETWEEN '2020-01-01'::timestamp
                                 AND '2020-06-30'::timestamp;

EXPLAIN ANALYZE SELECT date_trunc('month', a), date_trunc('day', a)
   FROM t3 GROUP BY 1, 2;

Without expression and ndistinct statistics, the planner has no information about the number of distinct values for the expressions, and has to rely on default estimates. The equality and range conditions are assumed to have 0.5% selectivity, and the number of distinct values in the expression is assumed to be the same as for the column (i.e. unique). This results in a significant underestimate of the row count in the first two queries. Moreover, the planner has no information about the relationship between the expressions, so it assumes the two <literal>WHERE</literal> and <literal>GROUP BY</literal> conditions are independent, and multiplies their selectivities together to arrive at a severe overestimate of the group count in the aggregate query. This is further exacerbated by the lack of accurate statistics for the expressions, forcing the planner to use a default ndistinct estimate for the expression derived from ndistinct for the column. With such statistics, the planner recognizes that the conditions are correlated, and arrives at much more accurate estimates. 式統計とN個別値統計がなければ、プランナは式の異なる値の数についての情報がなく、デフォルトの評価に頼らなければなりません。 等価と範囲の条件は0.5%の選択性を持つと仮定され、式内の異なる値の数はその列の数と同じ(すなわち一意)と仮定されます。 これは、最初の2つの問い合わせでの行数の著しい過小評価という結果を招きます。 さらに、プランナは式の間の関係について情報がないので、2つのWHEREとGROUP BY条件が独立であると仮定し、その選択性を掛け合わせるので、集約問い合わせでグループの数のひどい過大評価をしてしまいます。 これは、式に対する正確な統計がないことによりさらに悪化し、その列のN個別値から導かれる式に対するデフォルトのN個別値評価を使うことをプランナに強制します。 そのような統計があれば、プランナは条件が相互に関係していることを認識し、ずっとより正確な評価をします。

互換性

There is no <command>CREATE STATISTICS</command> command in the SQL standard. 標準SQLにCREATE STATISTICSコマンドはありません。

関連項目