Postgresql 为什么我做左连接时不应用优化？
为什么列不向下推，并且未应用优化。 并在 当我使用整排变量时出现了问题。但在这里我不使用它们。 当我执行左连接或将此左连接放在CTE中时，查询运行缓慢 当我直接运行查询或将条件放入其中时，只需运行： 准备好 选择 协议id、系统周期、应用周期、， acc_i.ready作为acc_i_ready， acc_i.acc_期间作为acc_i_期间， acc_i.consumed_period作为acc_i_consumed_period， acc__.ready作为acc___.ready， acc_.acc_期间作为acc_期间， acc_.consumed_期间与acc___.consumed_期间相同 从订单 左连接acc_就绪“发票”，应用期，o acc_i上的acc_i就绪 左连接acc_就绪‘使用’、应用程序周期、o acc_ON acc_就绪 其中o.sys_period@>sys_time和o.app_period&&app_period 和协议_id=1736 选择* 准备就绪 当我在外面重复这个条件的时候 准备好 选择 协议id、系统周期、应用周期、， acc_i.ready作为acc_i_ready， acc_i.acc_期间作为acc_i_期间， acc_i.consumed_period作为acc_i_consumed_period， acc__.ready作为acc___.ready， acc_.acc_期间作为acc_期间， acc_.consumed_期间与acc___.consumed_期间相同 从订单 左连接acc_就绪“发票”，应用期，o acc_i上的acc_i就绪 左连接acc_就绪‘使用’、应用程序周期、o acc_ON acc_就绪 其中o.sys_period@>sys_time和o.app_period&&app_period 和协议_id=1736 选择* 准备就绪 -注意：我只重复这个！ 其中sys_period@>sys_time和app_period&&app_period 和协议_id=1736 当我拆分条件时，需要： 准备好 选择 协议id、系统周期、应用周期、， acc_i.ready作为acc_i_ready， acc_i.acc_期间作为acc_i_期间， acc_i.consumed_period作为acc_i_consumed_period， acc__.ready作为acc___.ready， acc_.acc_期间作为acc_期间， acc_.consumed_期间与acc___.consumed_期间相同 从订单 左连接acc_就绪“发票”，应用期，o acc_i上的acc_i就绪 左连接acc_就绪‘使用’、应用程序周期、o acc_ON acc_就绪 其中o.sys_period@>sys_time和o.app_period&&app_period 选择* 准备就绪 哪里 协议id=1736-不幸的是，这不用于索引扫描=为什么？？？ 当我将所有条件移到外部时，已经需要： 嗯，但我不会崩溃，是吗 准备好 选择 协议id、系统周期、应用周期、， acc_i.ready作为acc_i_ready， acc_i.acc_期间作为acc_i_期间， acc_i.consumed_period作为acc_i_consumed_period， acc__.ready作为acc___.ready， acc_.acc_期间作为acc_期间， acc_.consumed_期间与acc___.consumed_期间相同 从订单 左连接acc_就绪“发票”，应用期，o acc_i上的acc_i就绪 左连接acc_就绪‘使用’、应用程序周期、o acc_ON acc_就绪 选择* 准备就绪 其中sys_period@>sys_time和app_period&&app_period 和协议_id=1736 当我删除左连接只需要 准备好 选择 协议id、系统周期、应用周期 从订单 选择* 准备就绪 其中sys_period@>sys_time和app_period&&app_period 和协议_id=1736 比较：VS VS 在depesz上相同：VS VS 为什么第二、第三和第四个查询没有像第一个/最后一个查询那样优化？ 第四种情况是否有一些变通办法使其快速工作？ 要选择邮件列表中描述的其他字段，请参见上面的链接 第二种情况在我看来是违反直觉的，不是预期的行为 服务器版本是13.1 *第一个-条件仅在CTE内时 *第二-当此条件复制到CTE外部时 UPD进一步调查： 试试I1 这里，当函数在第一种和第二种情况下不稳定时，BitmapHeapScan应用于两个索引： 订单id协议id，订单id系统周期应用周期不包括 VS 试试I2 将acc_就绪功能更改为稳定后， 对于第一个查询，使用BitmapHeapScan。 对于第二个查询，IndexScan被错误地使用了？。 比较 这里我们看到内联为我们节省了2ms 和34ms，因为没有JIT生成。 但还是错误地需要额外4ms？当我在外面重复这种情况 在这里，我不期望额外的4ms时间，因为CTE内部的条件是不变的，所以时间也不应该有变化，对吗 试试I3 最后，当我删除order_id_sys_period_app_period_excl索引时，会再次使用BitmapHeapScan而不是较慢的索引Scan。 这是最快速的查询，只需 尚待解答的问题： 为什么IndexScan用于I2部分而BitmapHeapScan用于I1部分？ 为什么BitMapIndexScan不像在I3节中那样一个接一个地应用？最快案例<Postgresql 为什么我做左连接时不应用优化？,postgresql,postgresql-performance,Postgresql,Postgresql Performance,为什么列不向下推，并且未应用优化。 并在 当我使用整排变量时出现了问题。但在这里我不使用它们。 当我执行左连接或将此左连接放在CTE中时，查询运行缓慢 当我直接运行查询或将条件放入其中时，只需运行： 准备好 选择 协议id、系统周期、应用周期、， acc_i.ready作为acc_i_ready， acc_i.acc_期间作为acc_i_期间， acc_i.consumed_period作为acc_i_consumed_period， acc__.ready作为acc___.ready， acc
/p> 多亏了IRC的RhodiumToad： 一,。未应用优化，因为CTE包含易失性函数。 它已经准备好了 二,。对于第二个查询，额外的时间需要JIT生成。 比较