在sql server索引查询中写成如下
SELECT *
FROM TabEmp
WITH (INDEX(idx_TabEmp))
以同样的方式如何在 postgresql 中编写查询以及如何在 postgresql 中使用索引。
在sql server索引查询中写成如下
SELECT *
FROM TabEmp
WITH (INDEX(idx_TabEmp))
以同样的方式如何在 postgresql 中编写查询以及如何在 postgresql 中使用索引。
PostgreSQL 带有一个非常先进的计划器,它最好使用所有可能的方法以最有效的方式提供查询详细信息。
当涉及到索引时,只需在正确的列上创建它们,很可能是在FROM
(显式表示法)WHERE
或ORDER BY
子句中使用的列。正如文件所说:
一旦创建了索引,就不需要进一步的干预:当表被修改时,系统会更新索引,当它认为这样做比顺序表扫描更有效时,它会在查询中使用索引。
当然,您必须ANALYZE
查看表并查看EXPLAIN
输出,以了解数据库实际在做什么来处理您的查询。
编辑
我的主要日常工作是管理一组在 ORACLE 上运行的计费生产系统,所以我知道提示是什么。作为管理员,我非常了解我的架构和数据,并且在大多数情况下,我确实知道执行查询的最佳计划是什么。
现在,由于 ORACLE 提供了许多不同的功能,它的优化器根本无法“赶上”可能路径的数量。因此,他们采取了另一种方式并添加了提示。而且我确实使用它们,因为我没有其他方法可以强制执行我知道应该表现最好的具体计划,无论我如何处理相关关系的统计数据。
PostgreSQL 走了另一条路。他们没有提供提示,而是花费了大量时间来使规划器像今天一样好。我印象深刻,这就是 PostgreSQL 将所有其他 RDBMS 踢出圈的地方。恕我直言。
是的,并不是总能用 PostgreSQL 获得最好的计划。但是有办法达到目标。正如其他人已经指出的那样:
EXPLAIN (analyze, buffers)
例如http://explain.depesz.com/enable_*
设置来真正获得正确的计划;SET STATISTICS
您发现存在数据偏差的列;根据我使用 PostgreSQL 的经验,从来没有必要使用提示。尽管添加提示“又快又容易”,但我总是更喜欢通过常用方法解决性能不佳的查询,因为在数据分布或数据库使用模式发生变化的情况下提示可能会做得不好(很常见的场景)。
我看到提示的唯一地方可能有用:修复您正在使用/支持的闭源软件的生产问题。但是,如果您在推出新版本之前进行深入而彻底的 QA 和性能测试,情况也并非如此。
如果您仍然需要提示,请查看Oleg Bartunov和 Teodor Sigaev 的 Plantuner。此扩展不在标准 PostgreSQL 发行版中,但鉴于 Oleg 和 Teodor 属于核心 PostgreSQL 开发团队(他们为项目创建了 GIN、GIST 和 FTS),我希望代码相当稳定。