Search before asking
Motivation
Data evolution MERGE already pushes deterministic target-only partition predicates from the ON condition into SnapshotReader, allowing the general MERGE path to prune unrelated target partitions.
Self-merge on _ROW_ID also has a fast path that avoids the source scan, join, shuffle, and sort. However, this fast path only recognizes an exact _ROW_ID equality. Adding a supported target partition predicate disables the optimization:
MERGE INTO target t
USING target s
ON t._ROW_ID = s._ROW_ID
AND t.dt = '2026-08-31'
WHEN MATCHED THEN UPDATE SET ...
The query can prune target partitions, but falls back to the general MERGE path. We should allow partition pruning and the self-merge fast path to work together.
Solution
No response
Anything else?
Extend the self-merge matcher to recognize _ROW_ID equality combined with deterministic target-only partition predicates.
Push these predicates into SnapshotReader before split planning, then execute the existing single-scan Scan -> MergeRows -> Write path on the selected partitions.
The optimization should be limited to matched UPDATE/DELETE actions. Queries with WHEN NOT MATCHED, WHEN NOT MATCHED BY SOURCE, unsupported residual conditions, or dynamic predicates such as target.dt = source.dt should continue using the general MERGE path.
Are you willing to submit a PR?
Search before asking
Motivation
Data evolution MERGE already pushes deterministic target-only partition predicates from the
ONcondition intoSnapshotReader, allowing the general MERGE path to prune unrelated target partitions.Self-merge on
_ROW_IDalso has a fast path that avoids the source scan, join, shuffle, and sort. However, this fast path only recognizes an exact_ROW_IDequality. Adding a supported target partition predicate disables the optimization:The query can prune target partitions, but falls back to the general MERGE path. We should allow partition pruning and the self-merge fast path to work together.
Solution
No response
Anything else?
Extend the self-merge matcher to recognize
_ROW_IDequality combined with deterministic target-only partition predicates.Push these predicates into
SnapshotReaderbefore split planning, then execute the existing single-scanScan -> MergeRows -> Writepath on the selected partitions.The optimization should be limited to matched UPDATE/DELETE actions. Queries with
WHEN NOT MATCHED,WHEN NOT MATCHED BY SOURCE, unsupported residual conditions, or dynamic predicates such astarget.dt = source.dtshould continue using the general MERGE path.Are you willing to submit a PR?