Hi, all I really like the PostgreSQL approach - configure && make && make install. And usually there are no additional packages or builds required. Postgresql seems to be compiled everywhere - even on coffee machine. It would be great to see the same for cloudberry. Since PAX is quite complex feature it would be better to have a special option --enable-pax.
I believe we will continue to create RPM and DEB packages with all features enabled, so users can take precompiled binaries and start using PAX from scratch. But for those who want to contribute, they can easily compile their first binary and then enable features step by step. On Fri, May 9, 2025 at 11:05 AM Dianjin Wang <wangdian...@gmail.com> wrote: > 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 > >
