englefly opened a new pull request, #68019:
URL: https://github.com/apache/doris/pull/68019
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary:
`SELECT lazy_col AS x, lazy_col AS y FROM t ORDER BY x LIMIT 1` failed
planning with
`A expression contains slot not from children`.
The TopN order key is the alias slot, so that alias has to be computed below
the TopN.
`MaterializeProbeVisitor` only protects the order key slot itself (an order
key slot is in
`TopN.getInputSlots()`) and never resolves an identity alias down to the
column the alias reads.
The probe of the other output (`lazy_col AS y`) therefore resolved to the
base column `lazy_col`
and classified it as lazily materialized, so `LazySlotPruning` removed
`lazy_col` from the scan while
`lazy_col AS x` below the TopN still read it. The final `Validator` rejected
the resulting plan and
the query returned an error. With `fe_debug=true` the failure was caught
inside `LazyMaterializeTopN`
instead, which silently skipped lazy materialization (the query succeeded
but lost the optimization).
Reproduction (master, `fe_debug=false`):
```sql
create table t(sort_col int, lazy_col int) duplicate key(sort_col)
distributed by hash(sort_col) buckets 1 properties('replication_num'='1');
select lazy_col as x, lazy_col as y from t order by x limit 1;
-- ERROR 1105: A expression contains slot not from children
-- Slot: lazy_col#1 Children Output:{0, 4}
-- Plan: PhysicalProject[lazy_col#1 AS x#2, __DORIS_GLOBAL_ROWID_COL__t#4]
-- +--PhysicalLazyMaterializeOlapScan[PhysicalOlapScan[t]]
```
Fix: `LazyMaterializeTopN` resolves the TopN order keys through the identity
alias chain of the
Projects under the TopN and adds the resolved slots (plus the intermediate
alias slots) to
`requiredMaterializedSlots`, so the probe rejects every lazy candidate
backed by a column an order
key reads. The resolution stops at set operations, which the probe never
materializes through
(lazy materialization is not supported through set operations today; if that
ever changes, order
keys have to be resolved per branch).
Effect: affected plans now either keep only the ordering column materialized
(other columns are
still fetched lazily) or skip lazy materialization, and the plan stays
valid. Plans that order by a
plain column are unchanged.
### Release note
TopN lazy materialization no longer builds an invalid plan (no more
`A expression contains slot not from children`) when a query orders by an
alias of a column.
The column that feeds the order key is materialized during the scan, while
other columns keep using
lazy materialization.
### Check List (For Author)
- Test
- [x] Regression test
(`regression-test/suites/query_p0/topn_lazy/order_by_alias`)
- [x] Unit Test (`TopnLazyMaterializeTest`, `LazyMaterializeTopNTest`)
- Behavior changed:
- [x] Yes. Queries that order by an alias of a projected column no
longer fail planning; the
ordering column is kept materialized instead of being pruned from the
scan.
- Does this need documentation?
- [x] No.
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
--
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]
