GitHub user jianlirong added a comment to the discussion: [Proposal] Remove `gpcontrib/gpmapreduce` starting from Cloudberry 3.0
I agree with this proposal. >From our perspective, `gpmapreduce` is a legacy component with very limited >usage today, and we are not aware of any significant active user base relying >on it. More importantly, the data ecosystem has changed considerably since `gpmapreduce` was originally introduced. With the growing adoption of the Lakehouse architecture, there are now many more mature approaches for data interoperability between MPP databases and big data platforms, including external tables, FDWs, open table formats, and various compute/storage integration solutions. Compared with these newer approaches, `gpmapreduce` does not have any obvious advantage, either in terms of performance or user adoption. Its original use cases can generally be addressed more effectively through modern data integration and interoperability mechanisms. I also think this is an important part of keeping Apache Cloudberry moving forward. As an actively evolving open-source project, we need to not only continuously add support for new technologies and emerging use cases, but also periodically remove legacy components that no longer provide sufficient value. Otherwise, the codebase will inevitably become more complex and the maintenance burden will continue to grow. This is a common pattern in mature open-source infrastructure projects. For example, Linux continues to add support for new hardware architectures and platforms while also removing support for obsolete hardware and platforms when they are no longer widely used. This allows the project to evolve without carrying unnecessary legacy code indefinitely. In that sense, removing `gpmapreduce` is not just about removing an old feature; it is part of keeping Cloudberry's architecture and codebase focused on technologies that are relevant to its current and future users. Therefore, I support removing `gpcontrib/gpmapreduce` starting from Cloudberry 3.0. Keeping it in the 2.x line for existing users, as proposed, also seems like a reasonable migration path. Lirong GitHub link: https://github.com/apache/cloudberry/discussions/2030#discussioncomment-18522374 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
