Andrei Lepikhov：全局哈希表在PostgreSQL中卷土重来？
内容提要
PostgreSQL并行聚合测试显示，共享哈希表方案在均匀分布下可提速至4.82倍，但受数据倾斜影响，重击组占比超10%时性能下降。实现需处理锁竞争、内存限制和表达式解释器问题，且进程模型增加开销。建议采用分区策略，或限制于固定宽度状态以优化。
延伸解读
共享哈希表并行聚合的适用边界
文章测试表明，共享哈希表方案在数据均匀分布时效果显著，8个worker下可达4.82倍加速；但当“重击组”占比超过10%时性能下降，甚至可能比串行更慢。因此，实际应用中需依赖统计信息和MCV来评估数据倾斜程度，若最大热门值占比在2%以下可放心使用，5%-10%仍可尝试，超过则需谨慎。
PostgreSQL进程模型带来的额外开销
与论文中基于线程的引擎不同，PostgreSQL采用独立进程模型，共享内存分配在DSA中，无法直接使用指针和palloc，导致聚合状态需复制进出共享内存，且表达式解释器无法高效执行。锁竞争并非唯一瓶颈，LWLock本身开销大，且锁内可能执行任意代码，进一步加剧了性能问题。
分区策略与共享表的权衡
文章对比了多种并行聚合策略，指出分区（如SQL Server的Repartition Streams）在数据倾斜时更稳健，但实现复杂且需处理负载均衡。共享表方案虽能减少内存占用和避免Finalize阶段，但受限于进程模型和锁开销。作者认为，在PostgreSQL中分区策略可能更合适，但共享表在特定场景（如简单分组、SetOp）仍有潜力。
未来优化方向：限制聚合状态类型
为提升共享并行聚合的适用性，文章建议限制聚合状态为固定宽度的by-value类型，如count、整数和浮点数的sum，这样可完全去除锁，并恢复高效的表达式解释器。对于numeric等类型，可通过限制精度（如numeric(x,y)）转换为int128或int256来优化，但这需要修改聚合函数本身，是未来的研究方向。
Q&A
PostgreSQL中共享哈希表并行聚合相比传统方法能提升多少性能？
在均匀分布的数据上，使用共享哈希表的并行聚合可以显著提升性能，最高可达4.82倍（8个worker时）。即使有2%的重击组（heavy hitter）倾斜，也能达到4.49倍的加速。
共享哈希表并行聚合在什么情况下性能会下降？
当数据倾斜严重时，即重击组（heavy hitter）占比超过10%时，性能开始下降，甚至可能比串行执行更慢。例如，当重击组占比达到95%时，加速比仅为0.04倍。
PostgreSQL实现共享哈希表并行聚合的主要挑战有哪些？
主要挑战包括：1) 需要处理锁竞争，因为聚合操作需要更新共享状态；2) 内存限制，因为聚合状态可能动态变化，需要精确的内存管理；3) 表达式解释器无法直接用于共享内存中的状态，需要绕过；4) 进程模型增加了开销，因为PostgreSQL使用进程而非线程。
PostgreSQL中共享哈希表并行聚合与并行哈希连接（PHJ）的哈希表有何不同？
共享哈希表用于聚合时，由于需要同时进行查找和更新，必须加锁，而并行哈希连接（PHJ）分为插入和读取阶段，可以避免锁。因此，聚合的共享哈希表不能直接复用PHJ的哈希表，需要专门设计。
PostgreSQL中共享哈希表并行聚合对聚合函数有什么要求？
聚合函数需要支持共享内存中的状态，特别是对于by-reference类型（如numeric、text），需要额外的复制和复制回机制。此外，需要为每个聚合函数设置aggsharedsafe标志，以表明其可以在并行聚合中安全使用。
共享哈希表并行聚合在PostgreSQL中的实现是否适合所有场景？
不适合。它主要适用于数据分布均匀、重击组占比低（如低于2%）的场景。对于数据倾斜严重的情况，性能会下降。此外，它需要额外的内存管理开销，并且目前不支持JIT编译，因此对于复杂表达式可能性能不佳。
PostgreSQL中共享哈希表并行聚合相比分区策略有何优缺点？
优点：共享哈希表可以减少内存占用，避免Finalize阶段，从而减少操作。缺点：实现复杂，需要处理锁竞争和内存管理，且受数据倾斜影响大。分区策略（如按组哈希分发）在数据倾斜时更稳定，但可能引入额外的I/O和重分区开销。
PostgreSQL中共享哈希表并行聚合的未来改进方向是什么？
未来改进方向包括：1) 采用无锁设计，例如限制为固定宽度的by-value状态，使合并操作成为原子操作；2) 优化聚合函数，如使用int128/int256代替numeric；3) 改进表达式解释器以支持共享内存；4) 扩展应用到SetOp和DISTINCT等操作。
