Hi all, Wishing you a happy Labor Day.
I DON'T AGREEthat disabling PAX by default is a good idea. 1. About "Build Consistency with Other contrib Modules" You may notice that the AO table does not exist as an extension in CBDB/GP, which is of course partly for historical reasons. But in fact, when we were working on PAX, we had to clean up a lot of AO-specific logical in the CBDB kernel. Currently, the AO tables could be modularized and move to the contrib/gpcontrib, but we did not do so. PAX was designed to replace the AO table, and the current version of PAX has more feature than AO and better scalability. It also performed better than the AO table in some tests. If you still think that all extension in contrib should disabled, Then CBDB will completely serve as a subset of GP. 2. About "Reduce Build Failures" Ed has mentioned compilation improvement suggestions before, and PAX will make corresponding compilation changes later. 3. About "Optional Nature of the Feature" Which part do you think is the "core feature"? Although PAX is an optional AM function, it is superior to AO table in all aspects. Is there enough evidence to show that user don’t need PAX? If we do disabled PAX by default, That will make users less aware of what PAX does. Finally, I always think that we should "solve problems when they occur" instead of avoiding them. As a new feature, PAX will encounter many problems before it matures, and we should not avoid these problems. If we just avoid problems blindly, CBDB will become a subset of GP with many useless features. Thanks Jiaqi At 2025-04-25 14:23:37, "Dianjin Wang" <wangdian...@gmail.com> wrote: >Hi all, > >I’d like to bring up a point regarding the PAX recently merged into >the main branch. > >Currently, the PAX is enabled by default in configure, and users need >to explicitly disable it via `--disable-pax` option. However, this >behavior is inconsistent with most of the other extensions under the >contrib/ or gpcontrib/ dir, which are typically disabled by default >unless explicitly enabled. > >I believe it would be more user-friendly and consistent to change the >default behavior of PAX to disabled, requiring users to opt-in via >`--enable-pax`. > >Here’s why: > >1. Build Consistency with Other contrib Modules: Most contrib plugins >are not enabled by default. Changing PAX to follow this pattern aligns >with user expectations, especially for long-time Greenplum users. > >2. Reduce Build Failures: PAX currently requires downloading several >submodules during the build. For users who install Cloudberry from >source without prior knowledge of this requirement, this will lead to >build failures, which can be confusing and frustrating. > >3. Optional Nature of the Feature: PAX, while valuable, is not a core >feature that every user will need. Letting users opt in to building it >makes the installation process simpler for the general case. > >We can also update the build instructions and documentation to clearly >indicate how to enable PAX if needed (--enable-pax) and how to fetch >its required submodules. > >I’d love to hear your thoughts on this. If there’s a consensus, that >would be better to make this change before our release 2.0. > >Best, >Dianjin Wang > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org >For additional commands, e-mail: dev-h...@cloudberry.apache.org
