慢查询影子赛道
慢查询出现时，让 AI 查询计划在生产形态副本上与 Postgres 实测竞速，只交付可验证、可回退的赢家。
数据库团队看到新一代小模型能提出更快的查询执行路径后，仍不敢把建议直接交给生产环境。一个看似更快的方案可能在特定参数下耗尽内存，或让别的请求长时间等待，必须在真实负载形态里先跑赢原有方案。
团队接入慢查询日志，再提供一套与生产结构相同、不会写入数据的副本。系统从日志中挑出高成本查询，让 Postgres 原本选定的执行路径和模型给出的候选路径重放同一批参数与数据分布。
每轮对比都会核验返回结果是否完全一致，并记录延迟、内存占用和是否拖慢其他请求。只有持续胜出的候选才会生成一张补丁卡，列明适用的参数范围、预期节省和一键退回原路径的开关。工程师可以先批准某一类查询，再逐步扩大覆盖范围。
起步时只处理只读查询，不触碰写入、表结构调整或自动上线。模型负责提出候选，是否投入生产仍由团队确认；产品交付的是跑过实测的执行方案，不是一段要求人凭感觉采纳的优化建议。
为什么是现在
9月16日，一项实验展示了 4B 模型在 JOB 评测中，从最多 15 个候选里选出 1.81x 的查询计划。S1 截至9月17日观测，文章在 Hacker News 排名第5，录得370分和75条评论；讨论随即转向这些结果能否经受真实生产负载。S2
目标用户
面向维护 PostgreSQL 分析负载的平台工程师、DBA 和后端负责人。触发时刻是某类只读查询反复变慢，团队已拿到一条模型优化建议，却没人愿意直接改生产计划。此时人工读 EXPLAIN 已不足以证明收益，因为参数分布、缓存状态和并发干扰都会改变结果。他们需要把上线争论变成可重复的副本实测。
最小切入点
从只读 SELECT 和单一 PostgreSQL 大版本切入。用慢查询日志或 `pg_stat_statements` 找出高成本指纹，再收集可获得的绑定参数。候选生成可复用 qorl 的结构化 PlanAction 思路，并由 `pg_hint_plan` 控制连接顺序、扫描和并行策略。S1 回放器执行 `EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)`，分开记录规划、执行和临时块指标。结果集由客户端流式落盘，并在同一数据快照下逐行核验。首版不声称精确测出执行期峰值内存，而是设置 `work_mem`、超时和临时文件硬上限。每个候选都与原生计划交错运行，降低缓存热度和后台抖动带来的偏差。
以小博大
第一批用户可从 PostgreSQL 性能顾问、数据平台工程师和自托管 SaaS 团队中寻找。他们手里通常已有脱敏副本，也能判断一次加速是否值得上线。开源一个本地回放器，让用户生成可分享的计划对比报告。围绕真实慢查询发布复现实验，展示失败候选为何被淘汰。Hacker News 原讨论和 PostgreSQL 社区适合触达愿意试验的早期用户。
竞品与缝隙
- pganalyze Query Advisor 与 WorkbooksGoogle
- pganalyze Query Advisor 会持续分析执行计划，识别低效嵌套循环等问题。它还能生成查询改写或规划器提示，并在 Workbooks 中对不同参数集做基准测试。优化是否上线仍由用户控制。S3 这已经覆盖发现、建议和人工验证的大段流程。公开文档的重点仍是已知反模式和确定性规则。慢查询影子赛道的缝隙，是接收模型提出的更广候选，再用真实数据分布逐个淘汰。评测还要加入并发请求受损、资源上限和持续胜出条件。最终交付物不是一条建议，而是限定参数范围的补丁卡。若 pganalyze 扩大候选生成与负载回放能力，这个缝隙会迅速缩小。
- Bao for PostgreSQLGoogle
- Bao 是面向 PostgreSQL 的学习型查询优化器。它通过粗粒度提示影响原生规划器，并根据执行反馈更新模型。它既可自动选择，也能仅作为顾问给出提示。S4 Bao 还提供预探索模式，可在指定时间测试查询，并阻止已预探索查询采用回退计划。它已经证明了“先探索、再利用”的基本路径。其公开实现面向 PostgreSQL 12，并需要数据库扩展和独立服务。慢查询影子赛道可把重心放在团队审批，而不是在线探索。它还要核验完整结果，复现实际参数分布，并测试候选是否拖慢其他请求。补丁卡需明确适用范围、资源证据和停用开关。这些运维护栏比单纯预测哪条计划更快更接近生产采购理由。
怎么赚钱
按受管数据库实例订阅收费。基础版包含只读副本回放、候选对比和补丁卡。高阶版增加并发压测、审批权限、历史回归与私有部署。模型调用和回放算力可设月度额度，避免重查询让成本失控。
反方视角
副本上的赢家可能只是适应了当前缓存和统计信息。数据增长、参数偏移或 PostgreSQL 升级后，优势可能反转。为了覆盖这些变化，团队要保存代表性参数，并定期重跑整套候选。回放本身会消耗大量计算和存储资源，长查询还可能拖慢副本同步。结果核验也不轻松，无排序结果、浮点值和易变函数都需单独处理。PostgreSQL 对执行期峰值内存的观测并不完整，只看延迟和临时块容易漏掉资源风险。生产落地若依赖 `pg_hint_plan`，还要承担扩展安装、版本兼容和提示失效的运维成本。候选数量一多，验证成本可能高于节省的数据库费用。