主页 / dba / 问题 / 322000
Accepted
J.Hudler
Asked: 2023-01-12 10:58:24 +0800 CST

Postgresql - 长列选择/投影列表导致性能不佳

  • 772

我有一个结构上相当“简单”的查询，基本上包含这些子句：

SELECT
  [650 columns here]
FROM
   MAIN_TABLE
   (Several Joins)
WHERE
   (Some conditions in MAIN_TABLE plus some others)

有人可以看出，列投影相当大。SELECT当我说查询“简单”时，我的意思是它在子句中有几 (3) 个非常简单的子查询。除此之外，它没有 CTE、Join 子句中的子选择、分组、排序等。

此查询在 20 秒到 25 秒之间跳来跳去完成。

现在，如果我随机开始删除其中一些列，在某个时候，查询性能会突然显着提高（从 20 秒到 1-2 秒）。

如果我导出数据库（现在很小，新部署，总共 ~1Gb 大小）并在我的开发机器上运行相同的查询，它运行得更快：0.5s

我想，在某种程度上，引擎在获取结果之前必须使用一些磁盘缓冲区作为中间存储。让我感到困扰的是，此列选择修改无缘无故地改变了查询计划（即查询起始表本身）的最内部性能。

我怎样才能正确诊断正在发生的事情并解决这个问题 - 有什么建议吗？

更多信息

  • PostgreSQL 版本 14.5
  • 操作系统：Rocky Linux 9.0 (Blue Onyx)
  • 遵循基于 pgTune 建议的参数 - 服务器的 CPU/RAM 比现在需要的多得多
  • 我已经为会话将 WORK_MEM 参数设置为较大的值（原始值的 100 倍），结果相同。

慢查询计划

快速查询计划（增加了 10000 行限制）

快速查询计划（删除了一些列）

postgresql

1 个回答

  1. Best Answer

    事实证明，在这种情况下，几乎整个处理时间都与 JIT 查询有关。

    设置会话或系统范围的postgres.conf标志jit=off解决了这个问题。

    特别感谢@jjanes，他指导了分析器的使用（我承认我对此持怀疑态度）。

    前perf report3 行是：

    Overhead  Command     Shared Object         Symbol
  39.31%  postmaster  libLLVM-13.so         [.] llvm::SUnit::addPred
   7.80%  postmaster  libLLVM-13.so         [.] llvm::ScheduleDAGInstrs::addChainDependencies
   6.90%  postmaster  libLLVM-13.so         [.] llvm::MachineInstr::mayAlias
    • 1

相关问题