我有两个数据库服务器都处于“测试”模式，其中一个预计会被提升到生产服务器。因此，规格不同以及一些配置，但我们发现动力不足的服务器会产生更好的查询计划，因此查询速度更快。
统计：
两个系统的数据大致相同，金额如下：
Size | Part
--------------------
1.47 TB | Entire DB
871 GB | Tables
635 GB | Indexes
较大的数据库服务器具有以下规范：
RAM：500 GB
CPU：16核心2.0 GHz Intel
使用SSD
Postgres 10.0
Memlock设置为专门为Postgres保留485 GB
Postgres设置：
shared_buffers：125 GB
work_mem：36 MB
effective_cache_size：300 GB
random_page_cost：1
default_statistics_target：1000
查询计划：https://explain.depesz.com/s/9Ww6
较小的服务器具有以下统计信息：
RAM：281 GB
CPU：4核心2.0 GHz Intel
使用SSD
Postgres 10.0
Memlock设置为专门为Postgres保留240 GB
Postgres设置：
shared_buffers：50 GB
work_mem：25.6 MB
effective_cache_size：150 GB
random_page_cost：4
default_statistics_target：100
查询计划：https://explain.depesz.com/s/4WUH
我们尝试切换random_page_cost，默认统计信息（后跟分析）和工作内存以相互匹配。在查询中的所有表上运行vacuum full之后，获得了最大的收益。
工作负载：此计算机是一个只读副本，用于将数据文件作为XML文件等提取。因此它接收复制数据并具有相当大的读取负载。
问题：我应该寻找什么来使这个查询在运行速度较慢的大型服务器上更高效？理想情况下，此查询运行速度比在较小的服务器上运行速度快得多。看起来我们已经缩放，我们无法正确设置设置以利用我们的硬件。必须有一些我忽略的东西。
编辑：我把非混淆的计划放了。我也试过从1000增加到3000的统计数据，这对计划没有帮助。更改random_page_cost以匹配服务器也是如此。
答案 0 :(得分：0)
两台机器上的PostgreSQL配置完全不同，因此查询计划不同也就不足为奇了。特别是random_page_cost会产生很大的影响。
您绝对应该使用不同的shared_buffers设置来衡量您的工作负载：您的工作量可能太高（通常，8GB是合适的）。
但我认为这两个你的查询计划都很糟糕，你的问题就在另一个地方。
优化程序错误地估计了showtimes.mappable_program上的索引扫描返回的行数，这种错误导致后来更糟糕的错误估计和错误的计划选择。
尝试增加列上统计信息的密度：
ALTER TABLE showtimes.mappable_program ALTER mapping_scheme_id
SET STATISTICS 1000;
然后ANALYZE表格。
如果不能解决问题，请通过替换
来修改查询WHERE COALESCE(mp2.ignore::integer, 0) = 0
与
WHERE mp2.ignore = '0' OR mp2.ignore IS NULL
这可能有助于优化器更好地估计条件。