fix(frontend): fix row filter with pk diff order type #19797
Conversation
xxhZs
changed the title
| match order_type { | ||
| Some(o) => { | ||
| if o != column_order.order_type { | ||
| all_added = false; | ||
| break; | ||
| } | ||
| } | ||
| None => order_type = Some(column_order.order_type), | ||
| } |
There was a problem hiding this comment.
I think the check here will pass if the PKs are all ordered desc:
create materialized view mv1 as select * from t1 order by v1 desc, v2 desc, v3 desc;
However, in this case, I think the optimization is not applicable.
There was a problem hiding this comment.
We just need to make sure that the order type of all the pk's is the same, in the row_seq_scan_exec will generate the appropriate scan according to the order type of the first pk to scan the data.
There was a problem hiding this comment.
Got it. That means when all pks are ordered desc, with the following scan range:
ExprType::GreaterThan => {
(Bound::Included(pk_struct), Bound::Unbounded)
}
the storage scan will be done by scanning from Bound::Unbounded to Bound::Included(pk_struct)
| match order_type { | ||
| Some(o) => { | ||
| if o != column_order.order_type { | ||
| all_added = false; | ||
| break; | ||
| } | ||
| } | ||
| None => order_type = Some(column_order.order_type), | ||
| } |
There was a problem hiding this comment.
Got it. That means when all pks are ordered desc, with the following scan range:
ExprType::GreaterThan => {
(Bound::Included(pk_struct), Bound::Unbounded)
}
the storage scan will be done by scanning from Bound::Unbounded to Bound::Included(pk_struct)
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Checklist
Documentation
Release note