背景

1、产品的问题点

• 世界上最痛苦的事情莫过于

• • 打开了一个网页, 结果鼠标漏斗不停的转呀转.
  • 执行了1条SQL, 但是不知道它什么时候能跑完.

• PG 无法预测大查询剩余执行时间

2、问题点背后涉及的技术原理

• 用户提交SQL后, 数据库经过parse, query rewrite, plan, execute几个阶段执行. 用户等待执行结果的返回.
• 执行过程并不知道跑到哪个NODE了, 已执行的NODE代价估算是多少, 花了多少时间? 还有哪些NODE没有执行, 分别的代价估算是多少, 预计还要花多久?

• • 执行计划是什么, 当前执行到哪里了, 每个步骤花了多少时间, 扫描了多少条记录, 多少个数据块, IO时间多少, op CPU 多少. 还剩多少时间. 返回多少行, 已返回多少行, 花了多少时间.
  • 《DB吐槽大会,第12期 - 没有自动成本校准器》

3、这个问题将影响哪些行业以及业务场景

• 通用

4、会导致什么问题?

• 当任务不可预期时, 无法对此作出正确的响应, 例如

• • 报表类的业务, 每天2点开始跑报表, 早上8点老板们需要拿到报表结果进行重大决策, 现在是6点半, 报表还没跑完, 还剩多久能跑完? 8点前能不能跑完? 接下来应该怎么办?

5、业务上应该如何避免这个坑

• 《官人要杯咖啡吗? - PostgreSQL实时监测PLAN tree的执行进度 - pg_query_state - Oracle 兼容10046 - progress》
• 把代价因子参数校准为时间为标准, 这样就可以得到较为准确的单个SQL的执行时间.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理复杂度增加.

7、数据库未来产品迭代如何修复这个坑

• 通过执行计划的每个node的代价以及已执行的过程和代价(行选择性估算、代价 与 实际行选择性、耗费时间等对齐估算)进行校准, 估算剩余时间.
• 用户可配置

• • 开关控制: 打开或关闭
  • 阈值控制: 当代价大于多少的时候, 跟踪执行过程

• 社区可能在努力了, https://commitfest.postgresql.org/34/3142/