PAX, as a storage plugin, has been contributed to the community. Should we turn on pax by default, encourage users to use it more, provide more feedback to help polish the product, but also provide an option to turn it off for unwanted users? We can make submodule init automated to reduce the impact on other users.
Best regards, Max Yang On Tue, May 6, 2025 at 11:10 AM jiaqi.zhou <jiaqi...@163.com> wrote: > 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 >
