zhaixiangli opened a new issue, #66879: URL: https://github.com/apache/doris/issues/66879
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Description Sequence mapping enables multiple input streams to update independent column groups in a UNIQUE KEY table while preserving each group's ordering. This capability was introduced by #54936. For a Merge-On-Read table, a predicate on a sequence-mapped value column cannot generally be pushed down as a final filter before merging physical rows. A stale physical row may match while the latest logical row for the same key does not, and different sequence groups may live in different physical rows. Consequently, selective equality or IN predicates may still scan and merge many physical rows before residual evaluation, especially on wide tables with many rowsets. The MOR value-predicate pushdown control in #60513 targets workloads where values are stable across rowsets; sequence mapping requires a different correctness model because each value group has an independent sequence. The enhancement should preserve normal MOR merge and residual evaluation as the final correctness layer, remain disabled by default, and introduce no data-format, tablet-meta, or index-format changes. ### Solution Add an optional two-phase candidate-key scan for UNIQUE MOR tables with sequence mapping: 1. Identify EQ and IN predicates on sequence-mapped value columns with inverted indexes. 2. Scan physical rows per sequence group and collect a conservative set of UNIQUE KEY values. 3. Intersect candidate keys across independent sequence groups. 4. Convert final candidates to point-key ranges. 5. Run the normal MOR merge and all original residual predicates on those ranges. The first phase only builds a conservative key superset and never returns final rows. Empty candidates can prune a tablet. Key predicates assist the candidate reader but do not act as sequence-group drivers. Range, NOT IN, NULL, and OR remain residual-only. Fallback to normal MOR for partial scanner splits, missing indexed drivers, disabled/unavailable inverted indexes, excessive candidate count, or when runtime candidate cost reaches the full-scan estimate: `candidate_scan_rows + candidate_key_count * rowset_count` Expose profile counters for driver groups, candidate rows/keys, index downgrades, pruned tablets, build time, and fallback reason. Regression coverage will include stale physical matches, same/cross-group predicates, empty candidates, composite keys, key ranges, count/cost fallback, index-disabled fallback, and multi-tablet scans. An anonymized fixed-snapshot validation compared 65 OFF/ON query pairs; all complete outputs were byte-identical with no query errors. The largest gains occurred for empty or very small candidate sets, while broad predicates require the cost fallback. Related work: #54936, #60513, #62222. ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
