github-actions[bot] commented on code in PR #68580:
URL: https://github.com/apache/doris/pull/68580#discussion_r4122477153
##########
be/src/exprs/vexpr.cpp:
##########
@@ -895,6 +895,10 @@ Status VExpr::check_constant(const Block& block,
ColumnNumbers arguments) const
}
uint64_t VExpr::get_digest(uint64_t seed) const {
+ // A nondeterministic expression can give another result on the next run,
so do not cache it.
+ if (!is_deterministic()) {
Review Comment:
[P1] Treat `array_shuffle` as uncacheable in filter digests. Its unseeded
form uses `time(nullptr)`, and its seeded form advances one generator across
each execution block, so a row's permutation can change when `batch_size`
changes. Neither `array_shuffle` nor its `shuffle` alias is rejected by
`VectorizedFnCall::is_deterministic()`. For a slot-based order-sensitive
predicate on a DUP table, an all-false granule cached on one scan can therefore
hide a row that matches on the next. Please return zero for these calls unless
the seeded form is made row-stable, and add a cache-hit test.
##########
be/src/exprs/vexpr.cpp:
##########
@@ -895,6 +895,10 @@ Status VExpr::check_constant(const Block& block,
ColumnNumbers arguments) const
}
uint64_t VExpr::get_digest(uint64_t seed) const {
+ // A nondeterministic expression can give another result on the next run,
so do not cache it.
+ if (!is_deterministic()) {
Review Comment:
[P2] Avoid traversing descendants at every digest node. `is_deterministic()`
recursively checks all children, and the following `child->get_digest()` calls
repeat that check at each level. A deterministic unary chain of depth n
therefore needs O(n²) visits: BE permits depth 600 by default, or about 180,000
checks per digest. With condition cache enabled, `FileScannerV2` rebuilds this
digest for every file split, multiplying the work on many-file scans. Check
only this node's volatility or compute determinism and digest together in one
traversal while preserving the zero sentinel.
##########
be/src/exprs/vexpr.cpp:
##########
@@ -895,6 +895,10 @@ Status VExpr::check_constant(const Block& block,
ColumnNumbers arguments) const
}
uint64_t VExpr::get_digest(uint64_t seed) const {
+ // A nondeterministic expression can give another result on the next run,
so do not cache it.
+ if (!is_deterministic()) {
Review Comment:
[P1] Exclude non-immutable UDFs from condition-cache keys.
`VectorizedFnCall::is_deterministic()` only rejects five built-in names, while
FE allows Java/Python UDFs declared `STABLE` or `VOLATILE` and `TFunction` does
not carry their volatility. A slot-based UDF filter on a DUP table can reach
`SegmentIterator`; this guard then returns a nonzero digest. If the UDF rejects
a granule on one query and accepts it on the next, the cached all-false bitmap
skips matching rows. Please carry volatility to BE or conservatively return
zero for UDF calls, and cover a cache hit with a changing UDF.
##########
be/src/exprs/vexpr.cpp:
##########
@@ -895,6 +895,10 @@ Status VExpr::check_constant(const Block& block,
ColumnNumbers arguments) const
}
uint64_t VExpr::get_digest(uint64_t seed) const {
+ // A nondeterministic expression can give another result on the next run,
so do not cache it.
+ if (!is_deterministic()) {
Review Comment:
[P1] Exclude TIMEV2-to-date casts that use the query clock. The TIMEV2 cast
kernels for DATE, DATEV2, DATETIME, DATETIMEV2, and TIMESTAMP_NS build the date
from `RuntimeState::timestamp_ms()`, while `VCastExpr::get_digest()` treats the
same slot-dependent tree as cacheable. For example, `CAST(TIMEDIFF(dt1, dt2) AS
DATE) = DATE '2026-09-29'` can reject every row before midnight and match after
midnight under the same cache key; the old all-false bitmap then skips those
matches. Return zero for these casts or include query date in the key, and
cover the date rollover.
--
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]
