zhangwenchao-123 commented on PR #1188: URL: https://github.com/apache/cloudberry/pull/1188#issuecomment-3006828302
> ## Comparison with Greenplum's QuickLZ Removal Approach > I reviewed how Greenplum handled QuickLZ removal and noticed they took a different, more gradual approach that might be worth considering: > > ### Greenplum's Two-Phase Approach > 1. **[First commit](https://github.com/greenplum-db/gpdb-archive/commit/363887e4d6abb494956bfb409acc345b0afb4d68)**: Added `gp_quicklz_fallback` > GUC for backward compatibility > > * Existing quicklz tables continue working > * New quicklz specifications automatically convert to zstd > * Provides graceful degradation path > 2. **[Second commit](https://github.com/greenplum-db/gpdb-archive/commit/b2ddb8620cde72fe379604c5c6d8b2b33e02a276)**: Removed quicklz from build > system > > * Eliminated build-time support while keeping runtime fallback > > ### This PR's Approach > * Complete removal without fallback mechanism > * Cleaner codebase but higher risk of breaking existing installations > > ### Considerations > **Pros of current approach:** > > * Cleaner code, no technical debt > * Clear break from unsupported feature > > **Potential concerns:** > > * Existing tables with quicklz compression may fail on upgrade > * No migration path for users > * Could cause immediate failures without clear guidance > > ### Suggestions > 1. **If keeping current approach**: Add clear error messages pointing to migration docs > ```c > ERROR: QuickLZ compression is no longer supported. > Please use 'zstd' or 'zlib' compression instead. > For migration guidance, see: [documentation link] > ``` > 2. Alternative: Consider implementing a temporary fallback mechanism similar to Greenplum's approach for smoother user transition > > What's the team's preference on backward compatibility vs. clean removal for this change? > ## Comparison with Greenplum's QuickLZ Removal Approach > I reviewed how Greenplum handled QuickLZ removal and noticed they took a different, more gradual approach that might be worth considering: > > ### Greenplum's Two-Phase Approach > 1. **[First commit](https://github.com/greenplum-db/gpdb-archive/commit/363887e4d6abb494956bfb409acc345b0afb4d68)**: Added `gp_quicklz_fallback` > GUC for backward compatibility > > * Existing quicklz tables continue working > * New quicklz specifications automatically convert to zstd > * Provides graceful degradation path > 2. **[Second commit](https://github.com/greenplum-db/gpdb-archive/commit/b2ddb8620cde72fe379604c5c6d8b2b33e02a276)**: Removed quicklz from build > system > > * Eliminated build-time support while keeping runtime fallback > > ### This PR's Approach > * Complete removal without fallback mechanism > * Cleaner codebase but higher risk of breaking existing installations > > ### Considerations > **Pros of current approach:** > > * Cleaner code, no technical debt > * Clear break from unsupported feature > > **Potential concerns:** > > * Existing tables with quicklz compression may fail on upgrade > * No migration path for users > * Could cause immediate failures without clear guidance > > ### Suggestions > 1. **If keeping current approach**: Add clear error messages pointing to migration docs > ```c > ERROR: QuickLZ compression is no longer supported. > Please use 'zstd' or 'zlib' compression instead. > For migration guidance, see: [documentation link] > ``` > 2. Alternative: Consider implementing a temporary fallback mechanism similar to Greenplum's approach for smoother user transition > > What's the team's preference on backward compatibility vs. clean removal for this change? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
