Hi, all To move forward, How about adding a --disable-pax configuration flag first? Similar to --disable-orca, by default, the build would include PAX, but developers should have the option to exclude it if needed. When --disable-pax is specified, the build system should skip compiling PAX entirely.
On 2025/05/06 03:41:27 Max Yang wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org For additional commands, e-mail: dev-h...@cloudberry.apache.org
