在 PostgreSQL 中显示基数估计错误的示例查询

Question

我正在开发一个使用 PostgreSQL9.3 的项目。我使用下面的查询来展示选择性估计错误如何导致使用 PostgreSQL8.3 在 TPC-H 工作负载上的查询执行时间增加数倍。

select 
    n_name, 
    sum(l_extendedprice * (1 - l_discount)) as revenue 
from 
    customer, 
    orders, 
    lineitem, 
    supplier, 
    nation,
    region 
where 
    c_custkey = o_custkey 
    and l_orderkey = o_orderkey 
    and l_suppkey = s_suppkey   
    and c_nationkey = s_nationkey 
    and s_nationkey = n_nationkey 
    and n_regionkey = r_regionkey 
    and (r_name='ASIA' or r_name='AFRICA') 
    and o_orderdate >= date '1994-01-01' 
    and o_orderdate < date '1994-01-01' + interval '1 year' 
    and l_shipdate <= l_receiptdate 
    and l_commitdate <= l_shipdate + integer '90' 
    and l_extendedprice <= 20000 
    and c_name like '%r#00%' 
    and c_acctbal <=2400 
group by 
    n_name 
order by    
    revenue desc

问题在于 PostgreSQL8.3 选择了一个涉及大量 NestedLoop 连接的计划，因为对 lineitem 和客户的选择性估计错误很大。我认为这主要是由于 LIKE 模式匹配。但最佳方案应该是使用 Hash Joins。

最近我为我的项目升级到 PostgreSQL9.3 并观察到上述查询不再给出错误的计划。我花了一些时间试图在 TPC-H 1GB 数据上找到具有较大 基数估计错误 的查询，但到目前为止还没有成功。是否有任何 PostgreSQL 极客知道 TPC-H 基准测试中的一些现成查询或任何显示 PostgreSQL9.3 中基数估计错误的查询

Answer 1

这是为了回答comment by @Twelfth以及问题本身。

Three quotes from this chapter in the manual:
"Controlling the Planner with Explicit JOIN Clauses"

显式内连接语法（INNER JOIN、CROSS JOIN 或朴素的JOIN） 与在FROM 中列出输入关系语义相同，所以它 不限制连接顺序。

...

强制规划器遵循明确规定的连接顺序 JOINs，将join_collapse_limit运行时参数设置为1。（其他 下面讨论可能的值。）

...

以这种方式约束规划器的搜索是一种有用的技术 既可以减少计划时间，也可以将计划者引导至 好的查询计划。

我的大胆强调。相反，您可以滥用相同的方法将查询计划器引导到 bad 查询计划以进行测试。阅读整个手册页。它应该是有用的。

此外，您可以通过disabling alternative methods 逐一强制嵌套循环（最好只在您的会话中使用）。喜欢：

SET enable_hashjoin = off;

等
关于检查和设置参数：

• Query a parameter (postgresql.conf setting) like "max_connections"

强制实际估计误差

一种明显的方法是禁用autovacuum 并从表中添加/删除行。然后查询计划器正在处理过时的统计信息。请注意，其他一些命令也会更新统计信息。

统计信息存储在目录表pg_class 和pg_statistics。

SELECT * FROM pg_class WHERE oid = 'mytable'::regclass;
SELECT * FROM pg_statistic WHERE starelid = 'mytable'::regclass;

这让我有了另一个选择。您可以在这两个表中伪造条目。需要超级用户权限。
您并不认为我是新手，而是对公众的警告：如果您破坏了目录表中的某些内容，您的数据库（集群）可能会崩溃。您已收到警告。