mview: restore DELETE column pruning for tables with mlog
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Enhancement
Restore DELETE column pruning optimization for base tables that have a materialized view log.
### Background
PR #66204 introduced mlog DML writing. To ensure `mlogTable.RemoveRecord` receives complete row data (including all tracked columns), the planner's `pruneAndBuildColPositionInfoForDelete()` skips column pruning when the table has an mlog (`pkg/planner/core/logical_plan_builder.go`):
```go
// For base tables with mlog, disable delete column pruning to keep RemoveRecord row layout stable.
hasMLog := tblInfo.MaterializedViewBase != nil && tblInfo.MaterializedViewBase.MLogID != 0
if tblInfo.GetPartitionInfo() != nil || hasFK || nonPruned == nil || hasMLog {
```
### Current Behavior
When a base table has an associated mlog, DELETE statements read **all** columns of the table, even those that are neither part of the primary key nor tracked by the mlog. For wide tables (many columns) where the mlog only tracks a small subset, this causes unnecessary I/O and memory usage during DELETE operations.
### Expected Improvement
Implement selective column pruning that preserves columns needed by the mlog while still pruning truly unused columns. Specifically:
1. Identify the set of columns required by the mlog: the handle columns plus the `trackedBaseOffsets` columns.
2. In `pruneAndBuildColPositionInfoForDelete`, mark these columns as "required" (similar to how FK columns are handled) but still allow pruning of other columns.
3. Ensure the pruned row layout is consistent with what `mlogTable.RemoveRecord` expects when writing mlog entries.
This would restore the performance benefit of column pruning for DELETE on tables with mlogs, especially for wide tables where only a few columns are tracked.
### Related
- #18023
- #66204
Contributor guide
Research direction
Start in pkg/planner/core/logical_plan_builder.go at pruneAndBuildColPositionInfoForDelete, then trace the mlogTable.RemoveRecord row layout and the trackedBaseOffsets mentioned in the issue. Preserve handle and tracked columns while pruning other DELETE columns, and verify that the resulting layout remains compatible with mlog writes and avoids reading unused columns.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100