PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)

[grantzhou]

--- As of 2026-02-10T20:53:58.000Z ---

The discussion focuses on optimizing PGPROC structure alignment for better performance. Andres Freund suggests making PGPROC a power of two size to optimize GetPGProcByNumber() indexing, which currently requires expensive 64-bit multiplication instead of faster bit shifts. He notes this shows up in LWLock contention heavy workloads and recommends separating frequently-changed fields from static ones to avoid false sharing issues. Heikki Linnakangas proposes cache line alignment as a compromise, providing a patch that aligns to cache line boundaries rather than expanding to 1024 bytes. Bertrand Drouvot suggests reordering fields logically, which reduces the structure to 832 bytes but requires 64 bytes of padding when using explicit alignment. The participants agree on grouping related fields together for better cache behavior and readability, though Andres emphasizes the need for concrete benchmarks on large machines to validate performance improvements.

讨论重点是优化PGPROC结构对齐以提升性能。Andres Freund建议将PGPROC设为2的幂次大小来优化GetPGProcByNumber()索引操作，该操作目前需要昂贵的64位乘法而非更快的位移操作。他指出这在LWLock竞争激烈的工作负载中会出现问题，并建议将频繁变化的字段与静态字段分离以避免伪共享问题。Heikki Linnakangas提出缓存行对齐作为折中方案，提供了一个补丁将结构对齐到缓存行边界而非扩展到1024字节。Bertrand Drouvot建议逻辑性地重新排列字段，这将结构减少到832字节，但在使用显式对齐时需要64字节填充。参与者们同意将相关字段分组以获得更好的缓存行为和可读性，尽管Andres强调需要在大型机器上进行具体基准测试来验证性能改进。

participants - 参与者:

• andres@anarazel.de
• bertranddrouvot.pg@gmail.com
• hlinnaka@iki.fi