github-actions[bot] commented on code in PR #62304:
URL: https://github.com/apache/doris/pull/62304#discussion_r3212691845
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/rewrite/NestedColumnPruning.java:
##########
@@ -246,7 +301,22 @@ private static Map<Integer, AccessPathInfo> pruneDataType(
continue;
}
+ // Null-check-only access (e.g. col IS NULL / col IS NOT NULL):
type stays unchanged,
+ // but we must send the [col, NULL] access path to BE so it only
reads the null flag.
+ if (accessTree.hasNullCheckOnlyAccess()) {
+ if (skipDataSkippingOnlyAccessPath) {
Review Comment:
This MV-fragment skip only catches top-level `col IS NULL`/`IS NOT NULL`
cases. For a nested predicate like `struct_element(s, 'city') is not null`,
`hasNullCheckOnlyAccess()` is false because the root `s` has
`accessPartialChild`, so the code falls through and still emits `[s.city.NULL]`
plus a pruned `struct<city:...>` type even when
`skipDataSkippingOnlyAccessPath` is true. That can reproduce the same MV
temporary-fragment bug this flag is trying to avoid: the temporary rewritten
fragment only needs the nested null flag for filtering, but the final MV
rewritten plan may still need the full complex slot or another child. This is
distinct from the existing parent-NULL/allAccessPath threads; it is the
MV-rewrite skip path not covering nested NULL-only access. Please either
suppress nested data-skipping-only access paths under this flag as well, or add
a nested MV rewrite regression that proves the final plan cannot reuse a pruned
complex slot.
--
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]
