在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。因此该方法不是完全没有后果的。
如果你只是想知道另一个计划是什么，你只需要解释，而不是解释分析。这是更快，如果语句有副作用，也更安全。