什么可以证明长时间运行的EXPLAIN on查询(postgres)是合理的？
什么可以证明长时间运行的EXPLAIN on查询(postgres)是合理的？
提问于 2013-04-05 15:07:14
今天我反对一种新的查询优化问题。
我的问题是：
SELECT *
FROM sanrss
LEFT JOIN sanrum ON sanrum.sanrum___rforefide = sanrss.sanrss___rforefide AND sanrum.sanrum___rfovsnide = sanrss.sanrss___rfovsnide AND sanrum.sanrum___sanrsside = sanrss.sanrsside
LEFT JOIN sanact ON sanact.sanact___rforefide = sanrum.sanrum___rforefide AND sanact.sanact___rfovsnide = sanrum.sanrum___rfovsnide AND sanact.sanact___sanrsside = sanrum.sanrum___sanrsside AND sanact.sanact___sanrumide = sanrum.sanrumide AND sanact.sanact___sanrumide IS NOT NULL AND sanact.sanact___rsanopide='CCAM'
INNER JOIN saneds ON sanrss.sanrss___rforefide = saneds.saneds___rforefide AND sanrss.sanrss___rfovsnide = saneds.saneds___rfovsnide AND sanrss.sanrss___sanedside = saneds.sanedside
INNER JOIN sandia ON (sandia___rforefide, sandia___rfovsnide, sandia___sanrsside, sandia___sanrumide, sandiasig) = (sanrum___rforefide, sanrum___rfovsnide, sanrum___sanrsside, sanrumide, 1)
INNER JOIN rsaidp ON saneds.saneds___rforefide = rsaidp.rsaidp___rforefide AND saneds.saneds___rsaidpide = rsaidp.rsaidpide
WHERE sanrss.sanrss___rforefide = 'CHUL' AND sanrss.sanrss___rfovsnide = '201303_prov' AND sanrss.sanrssdtf >= '2013-01-01 00:00:00.0' AND sanrss.sanrssdtf <= '2013-03-31 23:59:59.999'
and sanrss.sanrsside = '7801512' 这不是真正的*，而是类似于选择的300个字段。
它在我们的一个服务器上很慢，但在另一个服务器上没有，所以我在它上面运行了一个解释来确定执行计划，这个服务器给我的总运行时间是0.5ms！但explain analyze的实际总工作时间约为3.6秒。
所以我试着只准备请求，这是一个认识到只有查询计划的计算才是造成巨大延迟的原因。
我尝试切换GEQO的一些会话参数(努力1，努力10，取消激活GEQO )，但对执行时间没有影响。对查询的所有表进行统计计算后，计算时间降至2.4秒。
奇怪的是，在较慢的服务器(相同的CPU和主板，但没有ssd存储)上，使用相同的参数执行完全相同的查询只需要15毫秒来确定查询计划和执行。两个服务器之间的主要区别是数据量，其中一个服务器中的数据是所有表中的问题的两倍。
那么，我应该考虑什么才能理解是什么因素降低了我的执行计划计算速度？
回答 1
Stack Overflow用户
回答已采纳
发布于 2013-04-08 14:59:16
看起来我们定义了一个太大全局统计目标。这个值是定义查询计划所必需时间。
降低价值已经解决了我们的问题。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/15827852
复制相关文章
相似问题
腾讯云开发者
