如何优化PostgreSQL的INTERSECT查询速度并使其采用类似BitmapAnd的执行计划？

这是个很典型的查询优化问题！先帮你理清楚两个查询效率差异的核心原因，再给出具体的解决办法：

为什么两个查询速度差这么多？ #

你已经抓准了关键：

• 第一个WHERE c1=555 AND c2=444查询，PostgreSQL优化器直接识别出这是同时满足两个列条件，所以采用了BitmapAnd策略：先通过两个单列索引分别生成符合条件的行的bitmap，再把两个bitmap合并，最后只做一次堆扫描就能拿到结果，全程高效且只扫描必要的数据块。
• 而INTERSECT查询默认的执行逻辑是分别执行两个子查询，各自取出符合c1=555和c2=444的全量结果（各近2000行），然后通过HashSetOp（哈希交集）来筛选出共同的id。这不仅要做两次完整的堆扫描，还要额外处理哈希去重和交集计算，自然耗时更长。

让INTERSECT使用BitmapAnd的方法 #

1. 临时禁用HashSetOp优化器选项 #

PostgreSQL的优化器默认优先用哈希集合操作处理INTERSECT/UNION这类语句，但我们可以临时关闭这个选项，引导它选择更高效的bitmap合并路径：

-- 会话级设置，仅影响当前连接的查询
SET enable_hashsetop = off;

-- 再执行你的INTERSECT查询
select id from mytable where c1=555 intersect select id from mytable where c2=444;

此时查看执行计划，应该会看到类似第一个查询的BitmapAnd逻辑——优化器会把两个子查询的条件合并，避免两次独立的堆扫描。

2. 改写查询，让优化器更容易识别等价逻辑 #

虽然INTERSECT在语义上和AND等价，但优化器有时不会自动转化。你可以用更明确的写法引导优化器，比如用EXISTS子句（效果和第一个查询几乎一致，但保留了“交集”的语义）：

SELECT id 
FROM mytable t
WHERE c1=555 
AND EXISTS (SELECT 1 FROM mytable WHERE id = t.id AND c2=444);

或者用JOIN代替INTERSECT，优化器也可能选择bitmap合并的执行路径：

SELECT DISTINCT t1.id
FROM mytable t1
JOIN mytable t2 ON t1.id = t2.id
WHERE t1.c1=555 AND t2.c2=444;

3. 优化索引和统计信息 #

• 如果这类查询非常频繁，建议创建复合索引：CREATE INDEX idx_mytable_c1_c2 ON mytable(c1, c2);（或c2,c1，根据查询频率选择顺序）。复合索引可以让第一个查询直接通过索引拿到结果，同时也能帮助优化器更好地处理INTERSECT的执行计划。
• 确保表的统计信息最新：运行ANALYZE mytable;，让优化器能准确估算行数，做出更优的执行计划选择。

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