Postgresql – 使用enable_nestloop = false查询运行速度更快.为什么规划师没有做正确的事情？

当我使用默认的enable_nestloop = true和enable_nestloop = false(~10秒)运行它时,我的查询运行速度慢了很多(约5分钟).

解释两种情况的分析结果：

机器A nestloop = true – http://explain.depesz.com/s/nkj0(~5分钟)
机器A nestloop =假 – http://explain.depesz.com/s/wBM(~10秒)

在另一个稍慢的机器上,复制数据库并保留默认的enable_nestloop = true需要大约20秒.

机器B nestloop = true – (~20secs)

对于上述所有情况,我确保在运行查询之前进行了ANALYZE.没有其他查询并行运行.

两台机器都在运行Postgres 8.4.机器A运行Ubuntu 10.04 32位,而机器B运行Ubuntu 8.04 32位.

这里提供了实际查询.它是一个具有许多连接的报告查询,因为数据库主要用于事务处理.

>如果不采用物化视图的方式,我可以做些什么来让规划师通过设置enable_nestloop = false来完成我所做的事情？
>从我所做的研究看来,计划者选择看似不理想的查询的原因是由于估计行与实际行之间的巨大差异.我怎样才能让这个数字更接近？
>如果我应该重写查询,我应该改变什么？
>为什么计划员似乎正在为机器B做正确的事情.我应该在两台机器上进行比较？

解决方法

如果查询计划程序选择次优查询计划,则可能会使用不完整或误导性信息.

有关服务器调整,请参阅此PostgreSQL Wiki page.特别要注意random_page_cost和default_statistics_target的章节.
另请阅读Statistics Used by the Planner和Planner Cost Constants手册中的相应章节.

更具体地说,它可能有助于增加以下列的统计目标：

ALTER TABLE postgres.products ALTER COLUMN id SET STATISTICS 1000;
ALTER TABLE postgres.sales_orders ALTER COLUMN retailer_id SET STATISTICS 1000;
ALTER TABLE postgres.sales_orders ALTER COLUMN company_id SET STATISTICS 1000;

ALTER TABLE goods_return_notes ALTER COLUMN retailer_id SET STATISTICS 1000;
ALTER TABLE goods_return_notes ALTER COLUMN company_id SET STATISTICS 1000;

ALTER TABLE retailer_category_leaf_nodes ALTER COLUMN tree_left SET STATISTICS 1000;
ALTER TABLE channels ALTER COLUMN principal_id SET STATISTICS 1000;

这些涉及过滤器导致的

huge difference between the estimated and actual rows.

还有更多.检查刨床与估算偏差很大的每一列.默认值仅为100.仅对带有>>的表有意义1000行.试验设置.之后对表运行ANALYZE以使更改生效.

它也可能有助于在postgres上创建部分索引(sales_orders.retailer_id)WHERE retailer_id IS NOT NULL(取决于常见的NULL值).

可能对您有帮助的另一件事是升级到最新版本9.1.这方面已经取得了一些重大进展.