Hi all, I would like to share some context regarding PR #1064 <https://github.com/apache/cloudberry/pull/1064>: “chore: compile postgres statically to reduce the PLT function call”.
Background and Motivation During recent TPC-DS benchmark tests on CloudberryDB, we observed that linking the postgres binary against libpostgres.so (the shared library) introduces overhead due to Procedure Linkage Table (PLT) function calls. This overhead was particularly noticeable in large-scale queries, resulting in 5-8% lower performance compared to a statically linked binary. Main Changes Static Linking: The PR changes the build process to statically link all *.o object files into the postgres binary by default, instead of linking against libpostgres.so. This reduces PLT overhead and improves runtime performance. Configurable Linking: To preserve user flexibility, a new --link-postgres-with-shared configure option is introduced. Users can explicitly choose whether to link postgres with the shared library or with object files, independent of whether libpostgres.so is built (which remains necessary for certain extensions). Extension Compatibility: The build system ensures that extensions like pax, which require libpostgres.so, remain compatible. When building such extensions, the system checks that the shared backend option is enabled. Test Infrastructure Improvements: The PR also migrates certain CI tests (like ic-cbdb-parallel) to use release builds instead of debug builds to avoid disk space issues, as statically linked binaries are significantly larger. Performance Impact Performance results from a 1TB TPC-DS run show that static linking reduces overall query duration by 5-8%. This improvement is mainly attributed to the reduction in PLT function call overhead. Compatibility and Usability By default, the static linking behavior matches Greenplum's approach. The new configure flag allows users to select their preferred linking method without sacrificing extension compatibility. Known Issues Statically linked binaries are much larger (e.g., postgres binary size grows from <100KB to over 180MB), which may lead to disk space concerns in CI or constrained environments. The PR addresses this by moving CI tests to use the smaller release binaries. If you have feedback or further suggestions, please review the PR or reply to this thread! Bests, Xun Gong
