我们正在尝试从 postgres 10 迈向 16，不久前我们已经尝试过降低版本 12 或 13，但添加了更新 我们将机器的性能不佳归咎于这些更新。 现在我们正在一台新机器上进行测试，我们有 2 个虚拟机，它们具有相同的资源，postgres.conf 中的配置也相同。 有问题的查询是： select numero, mov.id, mov.tipo_movimiento, mov.cliente_origen_id, mov.cliente_destino_id, mov.motivo_baja, mov.estado estado_movimiento, mov.tipo_notificacion, mov.fecha_movimiento, ( 从工业中选择 i.id 我加入 clientesprecintos con c .id_industria = i.id (其中 c.id = mov.cliente_origen_id) as industria_origen_id, (从 industria i 加入 clientesprecintos c 中选择 i.id c.id_industria = i.id (其中 c.id = mov.cliente_destino_id) as industria_destino_id from (values (0,'13704147270')) as precintos (position, numero) 左连接横向（选择 mp.id、mp.estado、mpt.clave 作为 tipo_movimiento、mp.cliente_origen_id、mp.cliente_destino_id、mpmb.clave 作为 motivo_baja、tn.clave 作为 tipo_notificacion、fecha_ini 作为 fecha_movimiento 来自 movimiento_piezas_rangos mpr 在 mp.id = mpr.movimiento_piezas_id 上加入 movimiento_piezas mp 在 n.id_movimiento_piezas = mp.id 上左连接通知 n 将 tipos_notificaciones tn 左加入 tn.id = n.id_tipo_notificacion 在 mpt.id = mp.tipo_movimiento_id 上加入 movimiento_piezas_tipo mpt 在 mpmb.id = mp.motivo_baja_id 上左加入 movimiento_piezas_motivo_baja mpmb 其中 numero::bigint 位于 mpr.desde 和 mpr.hasta 之间，并且 mp.estado 不在 ('ANULADO', 'RECHAZADO') 中 order by mp.fecha_ini desc limit 1 ) as mov on true 按 precintos.position 排序；
在具有 postgres 10 的机器上，响应时间约为 750 ms。 在带有 postgres 16 的机器上，响应时间达到 4 分钟。
查看文档，似乎与12版本相比有变化。 我们对查询进行了更改，直到找到 v16 的更优化解决方案： 选择 numero、mov.id、mov.tipo_movimiento、mov.cliente_origen_id、mov.cliente_destino_id、mov.motivo_baja、mov.estado estado_movimiento、mov.tipo_notificacion、mov.fecha_movimiento，（从行业中选择 i.id，我加入 clientesprecintos con c .id_industria = i.id (其中 c.id = mov.cliente_origen_id) as industria_origen_id, (从 industria i 加入 clientesprecintos c 中选择 i.id c.id_industria = i.id (其中 c.id = mov.cliente_destino_id) as industria_destino_id from (values (0,'15727625912')) as precintos (position, numero) 左连接外侧（ 选择 mp.id、mp.estado、mp.tipo_movimiento、mp.cliente_origen_id、mp.cliente_destino_id、mp.motivo_baja、tn.clave 作为 tipo_notificacion、mp.fecha_movimiento 从 （与 mp_consulta AS ( 选择 mp.id、mp.estado、mpt.clave 作为 tipo_movimiento、mp.cliente_origen_id、mp.cliente_destino_id、mpmb.clave 作为 motivo_baja、fecha_ini 作为 fecha_movimiento 来自 movimiento_piezas_rangos mpr 在 mp.id = mpr.movimiento_piezas_id 上加入 movimiento_piezas mp 在 mpt.id = mp.tipo_movimiento_id 上加入 movimiento_piezas_tipo mpt 在 mpmb.id = mp.motivo_baja_id 上左加入 movimiento_piezas_motivo_baja mpmb 在哪里 mpr.desde 和 mpr.hasta 之间的 numero::bigint 和 mp.estado NOT IN ('ANULADO', 'RECHAZADO')) 选择 * 从 ( 从 mp_consulta 选择* 联合所有 SELECT * FROM mp_consulta ORDER BY fecha_movimiento DESC LIMIT 1 ) 作为 union_mp 按 fecha_movimiento DESC 限制排序 1) mp 在 n.id_movimiento_piezas = mp.id 上左连接通知 n 将 tipos_notificaciones tn 左加入 tn.id = n.id_tipo_notificacion ) 作为 true 上的 mov 按 precintos.position 排序；
我们见过
如果更改是针对单个查询，那么不会有问题，但这是一个大型应用程序，我们不知道可能会遇到多少个查询 表现如此不同且糟糕，或者是否是相同的模式。
乍一看似乎是一些调度程序配置，这将允许在不更改 SQL 查询的情况下获得良好的结果。
升级后您可以尝试重新索引吗？我想这可能是原因 https://www.postgresql.org/docs/13/release-13.html#:~:text=More%20efficiently%20store,use%20this%20feature.
无论如何，您需要在升级前进行彻底检查，以确保系统在升级后正常工作，还有一些行为变化
请仔细阅读每个主要版本的发行说明以了解更改