Hi Jiaqi and all, Thanks for your reply and for sharing your insights. I’d like to respond with a few thoughts from a community and release readiness perspective.
1. Lack of transparency in introducing the PAX While I fully respect the engineering efforts behind PAX, we must also reflect on how the feature was introduced. There was no public design proposal or open discussion prior to its contribution. The PR was open for a few weeks, but it was too large to review effectively. The goals behind PAX might be well-understood within certain internal teams, but not yet widely discussed in the Cloudberry community. At that time, we rushed to merge it into the main branch to catch up with the release - I also gave my +1 to the related PRs. This is a valuable lesson for all of us — especially for large, impactful features, we need more transparency and community discussion, just like the ongoing one around perfmon[1]. I'm not meant to blame anyone, it's one part of the story of incubation. The key point is that the default enabling behaviour of PAX is also against the description in the doc[2]. This is why we have this discussion thread. I have created one PR on setting the PAX to be disabled by default[3]. Compared to the thousands of file changes in PAX, mine is too small, however, we have such a deep conversation here, quite interesting and proud. 2. PAX is enabled by default is beyond the users' expectations for now The concern is not whether PAX is valuable — it’s about how users perceive and experience it. Having PAX enabled by default breaks the general expectation from most users familiar with Greenplum or PostgreSQL. We must admit that most of Cloudberry users will be ones who migrate from the open-source Greenplum. This difference can lead to: * Confusing build failures * Extra burden on users' Cloudberry installation * Frustration during first-time installation, which may cause them to give up on Cloudberry entirely Already saw the failure happening from the PPMC members, I bet it will be the same for the general users, we can imagine that. Our goal is to help PAX mature through community feedback. The best way is to make it opt-in — let users choose to enable it, experiment with it, and report issues, rather than forcing it upon them. 3. Let’s give users the power to choose Instead of enabling PAX by default, we can: * Provide clear instructions on how to enable it * Share blog posts and documentation explaining its advantages and roadmap * Present it at community events (meetups, talks, etc.) This gives users the opportunity to understand what PAX is, why it matters, and decide whether it’s right for them. `--enable-pax` is meaningfully different from `--disable-pax`; the former has less burden on users' operations. Eventually, if the community widely adopts PAX and achieves consensus, we can consider enabling it by default in a future release through a public conversation like this. At least, we should disable PAX by default for the coming 2.0.0 release, which will be critical for Cloudberry as a newly incubating project. If we enable the PAX by default at this stage, we risk losing the opportunity to grow our user base. 4. Being different from Greenplum is not a problem — we are building an Apache community I understand your concern about Cloudberry becoming a “subset of Greenplum.” But in fact, we are already quite different: our community is open, the governance is collaborative, and we follow the Apache Way except for these existing great features, including PAX. That in itself sets Cloudberry apart. To summarize: I believe PAX is promising, and we should keep promoting it actively. But we should also respect users’ installation experience, at least in our first Apache release. Love to hear more voices! [1] https://github.com/apache/cloudberry/discussions/1087 [2] https://github.com/apache/cloudberry/tree/main/contrib/pax_storage/doc [3] https://github.com/apache/cloudberry/pull/1081 Best, Dianjin Wang On Fri, May 9, 2025 at 12:32 PM Zhang Mingli <avamin...@apache.org> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org For additional commands, e-mail: dev-h...@cloudberry.apache.org
