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]