虚拟化系统会影响解释计划吗?

发布于 2024-11-19 03:32:57 字数 224 浏览 3 评论 0原文

我在 Postgresql 上的解释计划上得到了奇怪且不同的结果。 Postgresql 服务器安装在 VMWare 计算机上,当对给定 SQL 查询执行多个解释计划时,会返回不同的结果。在我看来,硬件虚拟化可能会向 Postgresql 服务器提供“错误”信息,以便它返回“异常且有些随机”的成本测量结果。对于这些令人惊讶和奇怪的结果,我是对的还是有其他解释?

无论如何,如果您知道的话,我将不胜感激任何有用的文档。

I'm having strange and different results for explain plans on Postgresql. Postgresql server is installed on a VMWare machine and when executing several explain plans for a given SQL query, different results are returned. It seems to me that the hardware virtualization may provide "erroneous" information to Postgresql server so that it returns "anormal and somewhat random" costs measurements. Am I right or is there any other explanation for those surprising and strange results?

In any case, if you know any, I'd appreciate any helpful docs.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

不必你懂 2024-11-26 03:32:57

VACUUM 应该是数据库操作的常规部分。但这可能不是您问题的根源。

我们建议经常清理活动生产数据库
(至少每晚),以删除死行。添加后或
删除大量行,发出一个命令可能是一个好主意
针对受影响的表的 VACUUM ANALYZE 命令。这将更新
系统目录包含所有最近更改的结果,并允许
PostgreSQL 查询规划器在规划查询时做出更好的选择。

不建议日常使用 FULL 选项,但可能会
在特殊情况下很有用。一个例子是当您删除或
更新了表中的大部分行并希望表
物理收缩以占用更少的磁盘空间并允许更快的表
扫描。 VACUUM FULL 通常会比普通表缩小表更多
真空会。

由于连续执行的成本不同,一个在 VMWare 下,一个不在 VMWare 下,并且没有数据库更改,所以我认为虚拟化正在产生一些效果。我非常确定虚拟机的 RAM 似乎比直接硬件少,但我现在没有办法测试它,或者测试它对查询优化器的影响。

VACUUM should be a regular part of database operations. It's probably not the source of your problem, though.

We recommend that active production databases be vacuumed frequently
(at least nightly), in order to remove dead rows. After adding or
deleting a large number of rows, it might be a good idea to issue a
VACUUM ANALYZE command for the affected table. This will update the
system catalogs with the results of all recent changes, and allow the
PostgreSQL query planner to make better choices in planning queries.

The FULL option is not recommended for routine use, but might be
useful in special cases. An example is when you have deleted or
updated most of the rows in a table and would like the table to
physically shrink to occupy less disk space and allow faster table
scans. VACUUM FULL will usually shrink the table more than a plain
VACUUM would.

Since you got different costs on consecutive executions, one under VMWare and one without, with no database changes, I'd say virtualization is having some effect. I'm pretty sure that a virtual machine would appear to have less RAM than straight hardware, but I don't have a way to test that, or to test its effect on the query optimizer right now.

偏爱自由 2024-11-26 03:32:57

计划不会直接受到底层硬件的影响。它们是成本参数(例如,random_page_cost)、内存设置(例如,work_mem)和表统计信息的乘积。您应该能够轻松验证两个实例之间的参数设置是否相同。 (理想情况下,可以根据硬件特性对这些参数进行调整,然后在不同的系统上会得到不同的计划。)表统计数据取决于表中的实际数据(您没有提及是否有相同的数据)两个实例)和收集统计数据时的一些随机元素。确保 ANALYZE 已运行。如果你还是不明白,就把计划贴出来吧。

Plans are not directly affected by the underlying hardware. They are a product of cost parameters (e.g., random_page_cost), memory settings (e.g., work_mem), and table statistics. You ought to be able to verify easily whether the parameter settings are the same between your two instances. (Ideally one would make adjustments to these parameters based on hardware characteristics, and then you would get different plans on different systems.) The table statistics are dependent on the actual data in the tables (you did not mention whether you had the same data in both instances) and some random element when the statistics are collected. Make sure ANALYZE has been run. If you're still clueless, post the plans.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文