Postgres优化器同SQL不同语言参数生成不同执行计划的优化求助

从提供的执行计划可以明确核心问题：

• 针对English,Portuguese的查询中，Postgres对tip_cs_work表符合过滤条件的行数估计严重偏离实际（预估19099行，实际返回178642行），导致优化器错误选择了Hash Join，Hash构建耗时近200秒。
• 针对Dutch,Portuguese的查询中，优化器选择了Nested Loop，通过主键索引pca_work_pk1逐个关联，避免了大量数据的Hash计算，性能正常。

以下是可行的修复方案：

1. 简化冗余过滤条件 #

当前查询中Laguage = ANY ('{English,Portuguese}') AND Laguage = 'Portuguese'属于冗余条件，完全等价于Laguage = 'Portuguese'。冗余条件会干扰优化器的统计判断，直接简化后可减少优化器的分析负担：

-- 修改后的过滤条件
WHERE ... 
  AND "Case".ObjType LIKE 'Tran-TIP-CS-Work%'
  AND "Case".Laguage = 'Portuguese';

2. 更新表统计信息 #

Postgres优化器依赖准确的统计信息选择执行计划，当前统计信息严重偏离实际数据，执行以下命令强制更新统计：

ANALYZE tip_cs_work;
ANALYZE TAB1;

如果是超大型表或数据分布极不均匀的场景，可以提高统计精度（临时调整会话级别参数）：

SET default_statistics_target = 1000;
ANALYZE tip_cs_work;

3. 创建高效复合索引 #

针对查询中的过滤（Laguage、ObjType）和关联（Primarykey）需求，创建覆盖型复合索引，让优化器能同时完成过滤和关联操作，避免回表：

-- 基础复合索引
CREATE INDEX idx_tip_cs_work_lang_obj_pk ON tip_cs_work (Laguage, ObjType, Primarykey);

-- 如果ObjType是前缀模糊匹配，使用text_pattern_ops优化
CREATE INDEX idx_tip_cs_work_lang_obj_pk ON tip_cs_work (Laguage, ObjType text_pattern_ops, Primarykey);

4. 临时强制使用Nested Loop（应急方案） #

如果上述优化暂时无法生效，可以通过查询提示强制优化器选择Nested Loop，避免低效的Hash Join：

SELECT /*+ NESTLOOP("PC0", "Case") */ 
       -- 替换为你的实际查询字段
       "PC0".*, "Case".*
FROM TAB1 "PC0"
JOIN tip_cs_work "Case" ON ("PC0".Referencekey)::text = ("Case".Primarykey)::text
WHERE "PC0".OpId = 'CustomerService2ndLine'
  AND "PC0".ObjType = 'Assign-WorkBasket'
  AND "Case".ObjType LIKE 'Tran-TIP-CS-Work%'
  AND "Case".Laguage = 'Portuguese';

注意：该方案为临时应急手段，优先通过统计信息和索引优化解决根本问题。

5. 修复数据类型转换问题 #

执行计划中多次出现::text隐式类型转换（如Referencekey和Primarykey的关联），类型转换会导致索引失效或性能损耗。建议确保关联字段的原始数据类型一致，避免隐式转换。

内容的提问来源于stack exchange，提问作者Parth