在PostgreSQL中,我们可以在一个查询上使用“EXPLAIN ANALYZE”来获取给定SQL查询的查询计划。虽然这很有用,但我们是否能够获取优化器生成的(随后被丢弃的)其他候选计划的信息?这样,我们就可以自己对DBMS生成的一些候选项(例如前3项)进行分析。
vmdwslir1#
不,计划者会在计划尚未完全形成之前,就尽早地放弃这些计划。一旦它认为某个计划不可能是最好的,它就永远不会完成它的构建,所以它不能显示它。您通常可以使用各种enable_* 设置或 *_cost设置来强制它做出不同的选择并显示相应的计划,但很难准确控制不同的选择是什么。你也可以临时删除一个索引,看看没有这个索引会怎么样。如果你在一个事务中删除一个索引,然后执行EXPLAIN,然后ROLLBACK这个事务,它会回滚DROP INDEX,这样索引就不需要重建了,它只会被恢复。但是要注意的是,DROP INDEX会在表上建立一个强锁,并保持它直到ROLLBACK。因此该方法不是完全没有后果的。如果你只是想知道另一个计划是什么,你只需要解释,而不是解释分析。这是更快,如果语句有副作用,也更安全。
1条答案
按热度按时间vmdwslir1#
不,计划者会在计划尚未完全形成之前,就尽早地放弃这些计划。一旦它认为某个计划不可能是最好的,它就永远不会完成它的构建,所以它不能显示它。
您通常可以使用各种enable_* 设置或 *_cost设置来强制它做出不同的选择并显示相应的计划,但很难准确控制不同的选择是什么。
你也可以临时删除一个索引,看看没有这个索引会怎么样。如果你在一个事务中删除一个索引,然后执行EXPLAIN,然后ROLLBACK这个事务,它会回滚DROP INDEX,这样索引就不需要重建了,它只会被恢复。但是要注意的是,DROP INDEX会在表上建立一个强锁,并保持它直到ROLLBACK。因此该方法不是完全没有后果的。
如果你只是想知道另一个计划是什么,你只需要解释,而不是解释分析。这是更快,如果语句有副作用,也更安全。