原 GreenPlum在执行超过30个表的关联SQL时，产生执行计划很慢的解决办法（join_collapse_limit、from_collapse_limit）
Tags： 原创GreenPlum执行计划from_collapse_limitjoin_collapse_limit生成执行计划慢
现象
在GreenPlum中，某个SQL语句，包含超过30个表，在生成执行计划时，特别慢，超过1分钟，有的SQL甚至一直卡在生成执行计划的步骤，在gpcc中，观察到排队时间、运行时间、CPU时间等等这些参数都是-，获取不到数据。
分析
join_collapse_limit 和 from_collapse_limit 这两个参数在Greenplum和PostgreSQL中都用于控制优化器在处理复杂SQL查询（尤其是涉及多表连接和FROM子句的查询）时的行为。
1. join_collapse_limit
作用：
决定优化器在生成查询执行计划时，最多允许多少张表的JOIN操作被合并（即优化器是否重排JOIN的顺序）。
如果表的数量超过该限制，优化器会停止尝试重新排列JOIN顺序，而是按照SQL中的表关联顺序生成执行计划。Postgres查询优化器（planner）会在总项不超过配置就显式将内部JOIN结构重写为FROM项列表。 默认情况下，此变量的设置与from_collapse_limit相同，适用于大多数用途。 将其设置为1可防止对内部JOIN进行任何重新排序。 将此变量设置为介于1和from_collapse_limit之间的值可能有助于将计划时间与所选计划的质量进行权衡（更高的值会产生更好的计划）。
默认值：
20（即优化器最多重新排列20张表的JOIN顺序）。意义：
优化效果：
JOIN操作的顺序对性能影响极大，优化器尝试找到成本最低的JOIN顺序。
但随着表的数量增加，可能的JOIN顺序组合会呈指数级增长（n个表有(n-1)!种组合）。表数量小于或等于
join_collapse_limit：优化器会尝试所有可能的JOIN顺序组合，寻找最优计划。表数量大于
join_collapse_limit：优化器会根据SQL中FROM子句的顺序生成执行计划，而不尝试重排。性能权衡：
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！
