GitHub user yjhjstz added a comment to the discussion: [Proposal] Apache Cloudberry as PostgreSQL 19 Extensions
I agree that an extension-based architecture is a promising long-term direction. A practical first step would be to modularize individual components incrementally in the current Cloudberry codebase, rather than adopting the entire PostgreSQL 19 prototype at once. ORCA looks like a strong first high-value candidate. However, it would be useful to distinguish between: - the ORCA optimizer engine, which is relatively independent of PostgreSQL; and - the Cloudberry/PostgreSQL adapter, including Query-to-DXL translation, metadata access, DXL-to-PlannedStmt translation, Motion information, and fallback handling. Cloudberry already has a `planner_hook`, but ORCA initialization and invocation are still embedded in `standard_planner()`. A concrete first milestone could therefore be: 1. Move ORCA initialization, GUC handling, planner selection, and fallback logic into a `gp_orca` module. 2. Keep the ORCA engine unchanged where possible. 3. Isolate PostgreSQL-version-dependent code in a relatively small adapter layer. 4. Allow Cloudberry to build and run normally without the ORCA module. 5. Build and test the module independently, with explicit API versioning between `gp_orca` and the Cloudberry core. The acceptance criteria should include: - PostgreSQL planner fallback remains fully functional. - Loading or unloading ORCA does not change catalogs or storage formats. - Existing ORCA regression, TPC-H, and TPC-DS results remain unchanged. - The module can be upgraded independently within a documented compatibility range. - No ORCA-specific control flow remains in `standard_planner()`. After that, modules with well-defined PostgreSQL interfaces—such as AO/AOCS table access methods, external tables/FDWs, and the SQL compatibility layer—could be extracted incrementally. General-purpose hooks should also be proposed upstream whenever possible. I would leave `gp_core`—the dispatcher, Motions, interconnect, distributed transactions, snapshots, GDD, and FTS—until later. That is the part that ultimately determines whether Cloudberry can truly operate as PostgreSQL extensions, and it requires complete `isolation2` coverage together with latency, concurrency, and failure-recovery benchmarks. In short, ORCA would be an excellent first proof of the modularization approach, but its successful extraction would not by itself prove the feasibility of the entire extension-based architecture. The distributed execution and transaction layers remain the decisive test. GitHub link: https://github.com/apache/cloudberry/discussions/2065#discussioncomment-18889981 ---- 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]
