tuhaihe commented on code in PR #1629:
URL: https://github.com/apache/cloudberry/pull/1629#discussion_r3008790709


##########
.github/workflows/build-deb-cloudberry.yml:
##########
@@ -448,13 +452,14 @@ jobs:
         shell: bash
         env:
           SRC_DIR: ${{ github.workspace }}
+          CONFIGURE_EXTRA_OPTS: --with-gp-stats-collector

Review Comment:
   Thanks for the reply! I’d like to share a few perspectives on why including 
`--with-gp-stats-collector` in `configure-cloudberry.sh` might be a better 
long-term choice:
   
   1. CI/CD Stability & Consistency: Since `configure-cloudberry.sh` is the 
foundational script for our PR generation, CI pipelines, and developer 
environments, adding the flag here ensures that the extension is consistently 
compiled and verified with every code change. This prevents "silent" build 
breakages that might only appear during specific tests.
   2. Building vs. Enabling (Zero Runtime Impact): There is a clear distinction 
between `building` the binary and `enabling` the feature. As long as 
`shared_preload_libraries` doesn't include it and `gpsc.enable` defaults to 
off, the extension is essentially "dormant" on disk. It will have zero impact 
on database performance, memory, or stability for users who aren't aware of it.
   3. Avoid the "Recompilation Hurdle": Cloudberry is a massive project. If a 
user discovers this powerful monitoring tool later but finds it wasn't built 
into their binary, they would have to reconfigure and recompile the entire 
database. This "secondary build" requirement is a significant barrier to 
adoption.
   4. Alignment with Other Extensions: Following the precedent of `diskquota` 
or `PAX`, building by default significantly improves discoverability. It allows 
users to try this high-performance collector via a simple `CREATE EXTENSION` 
without needing a deep knowledge of build flags.
   
   Finally, for those power users with highly customized requirements, they are 
already accustomed to modifying `configure` options or scripts to suit their 
specific needs. We’ve already provided that flexibility, so we don't need to 
worry about them. For the majority of users, keeping it "built-in but dormant" 
provides the best "out-of-the-box" experience. So let's enable it by default?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to