Postgres查询优化

时间:2012-08-09 02:15:18

标签: indexing postgresql-9.0

在postgres 9.0上,将index_scan和seq_scan都设置为Off。为什么它会将查询性能提高2倍?

2 个答案:

答案 0 :(得分:1)

这可能有助于某些查询运行得更快,但几乎可以肯定会使其他查询更慢。这是用于诊断目的的有趣信息,但对于长期“解决方案”来说是一个坏主意。

PostgreSQL使用基于成本的优化器,该优化器根据扫描表格(通常通过autovacuum)和成本因素收集的统计数据来查看所有可能计划的成本。如果它没有选择最快的计划,通常是因为您的成本核算因素无法准确地为您的环境建模实际成本,统计数据不是最新的,或者统计数据不够精细。<​​/ p>

重新开启index_scanseq_scan之后:

  • 我一般认为cpu_tuple_cost默认为太低;我经常看到通过将其设置为0.03而不是默认值0.01来选择更好的计划;而且我从未见过那种覆盖导致问题。

  • 如果数据库的活动部分适合RAM,请尝试将seq_page_costrandom_page_cost同时缩减为0.1。

  • 请务必将effective_cache_size设置为shared_buffers的总和以及您的操作系统显示为缓存的内容。

  • 永远不要禁用autovacuum。您可能希望调整参数,但要非常小心地进行,只需进行少量增量更改和后续监控。

  • 您可能需要偶尔运行显式VACUUM ANALYZEANALYZE命令,尤其是对于刚刚进行了大量修改并即将在查询中使用的临时表或表。 / p>

  • 您可能希望增加default_statistics_targetfrom_collapse_limitjoin_collapse_limit或某些geqo设置;但是,如果没有比你迄今为止给出的更多细节,那么很难判断这些是否恰当。

您可以尝试在单个连接上设置不同成本因子的查询。当您确认适合整个组合的配置时(即,它可以准确地模拟您环境中的成本),您应该在postgresql.conf文件中进行更新。

如果您需要更有针对性的帮助,请显示表格的结构,查询本身以及查询运行EXPLAIN ANALYZE的结果。对操作系统和硬件的描述以及PostgreSQL配置也有很大帮助。

答案 1 :(得分:0)

为什么?

最合乎逻辑的答案是因为数据库表的配置方式。

如果没有您发布表格架构,我只能猜测您的索引没有高基数。

也就是说,如果您的索引包含太多有用的信息,那么它的效率会低得多,或者确实会慢一些。

基数衡量索引中行的唯一性。基数越低,查询就越慢。

一个完美的例子是索引中有一个布尔字段;也许你的数据库中有一个Contacts表,它有一个布尔列,记录真或假,取决于客户是否希望第三方联系。

平均来说,如果您确实'从*中选择*,其中OptIn = true';你可以想象你会回复一个很多的联系人;在我们的案例中想象50%的联系人。

现在,如果您将此“Optin”列添加到同一个表的索引上;按理说,无论其他选择器有多精细,你都会返回50%的表,因为'OptIn'的价值。

这是低基数的完美例子;它会很慢,因为涉及该索引的任何查询都必须选择表中50%的行;然后能够应用更多WHERE过滤器来再次减少数据集。

长话短说;如果您的指数包含坏字段或只是代表表格中的每一列;然后SQL引擎不得不求助于逐行测试。

无论如何,以上是你理论上的理论;但这是为什么查询突然开始花费更长时间的常见原因。

请填写有关您的数据结构,索引定义和真正慢的实际查询的空白!