描述

CREATE STATISTICS 将创建一个新的扩展统计信息对象，跟踪指定表、外部表或物化视图的数据。该统计信息对象将在当前数据库中创建，并由发出该命令的用户拥有。

CREATE STATISTICS 命令有两种基本形式。第一种形式允许收集单个表达式的单变量统计信息，提供类似于表达式索引的好处，而无需索引维护的开销。这种形式不允许指定统计信息的种类，因为各种统计信息种类仅指多变量统计信息。该命令的第二种形式允许收集多个列和/或表达式的多变量统计信息，可以选择指定要包含的统计信息种类。此形式还会自动对列表中包含的任何表达式收集单变量统计信息。

如果给出了模式名称（例如，CREATE STATISTICS myschema.mystat ...），则统计信息对象将在指定的模式中创建。否则，它将在当前模式中创建。如果给出，则统计信息对象的名称必须与同一模式中任何其他统计信息对象的名称不同。

参数

备注

您必须是表的拥有者才能创建读取该表的统计信息对象。但是，一旦创建，统计信息对象的所有权将独立于底层表。

表达式统计信息是按表达式计算的，类似于在表达式上创建索引，只是它们避免了索引维护的开销。表达式统计信息会自动为统计信息对象定义中的每个表达式构建。

规划器当前不使用扩展统计信息来估计表连接的选择性。此限制可能会在未来版本的 PostgreSQL 中删除。

示例

创建表 t1，其中包含两个函数依赖的列，即，知道第一列中的值足以确定另一列中的值。然后，在这些列上构建函数依赖统计信息

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);

如果没有函数依赖统计信息，规划器会假设两个 WHERE 条件是独立的，并将它们的选择性相乘，从而得出过小的行数估计。有了这种统计信息，规划器会识别出 WHERE 条件是冗余的，并且不会低估行数。

创建表 t2，其中包含两个完全相关的列（包含相同的数据），以及这些列上的 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)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 1);

-- invalid combination (not found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 2);

MCV 列表为规划器提供了有关表中经常出现的特定值的更详细信息，以及表中未出现的数值组合的选择性上限，从而允许规划器在两种情况下都生成更好的估计。

创建一个具有单个时间戳列的表 t3，并使用该列上的表达式运行查询。如果没有扩展统计信息，规划器就没有关于表达式数据分布的信息，并且会使用默认的估计值。规划器也没有意识到，截断为月份的日期值完全由截断为日期的日期值确定。然后在这两个表达式上构建表达式和 ndistinct 统计信息

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)
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;

如果没有表达式和 ndistinct 统计信息，规划器就没有关于表达式的不同值数量的信息，并且必须依赖默认的估计值。假定相等和范围条件的选择性为 0.5%，并且假定表达式中的不同值数量与列（即唯一）相同。这导致前两个查询中行数的严重低估。此外，规划器没有关于表达式之间关系的信息，因此它假设两个 WHERE 和 GROUP BY 条件是独立的，并将它们的选择性相乘，从而得出聚合查询中组数的严重高估。由于缺乏准确的表达式统计信息，迫使规划器对从列的 ndistinct 推导的表达式使用默认的 ndistinct 估计，这进一步加剧了这种情况。有了这种统计信息，规划器会认识到条件是相关的，并得出更准确的估计值。

兼容性

SQL 标准中没有 CREATE STATISTICS 命令。

另请参见