github-actions[bot] commented on code in PR #66788:
URL: https://github.com/apache/doris/pull/66788#discussion_r3785807350
##########
be/src/exprs/function/like.cpp:
##########
@@ -487,8 +602,21 @@ Status FunctionLikeBase::regexp_fn(const LikeSearchState*
state, const ColumnStr
}
// hyperscan compile expression to database and allocate scratch space
+bool FunctionLikeBase::should_fallback_to_re2(std::string_view regexp) {
Review Comment:
[P1] Guard the other public Hyperscan compilers
This checker is reachable only from `FunctionLikeBase::hs_prepare()`. The
same user-controlled regexp reaches Hyperscan directly through no-index
`FunctionMatchRegexp::execute_match()`, v1 indexed `RegexpQuery::add()`, the
`search()` DSL's v2 `RegexpWeight::regexp_scorer()`, and `multi_match_any` via
`constructRegexps()`/`hs_compile_multi()`. Therefore `(ab?c?d){1000,5000}`
still incurs the expensive compile on those public paths despite this change.
Move the guard into a shared Hyperscan compilation utility and invoke it before
each entry point; where no compatible fallback exists, reject before
compilation. Add no-index, indexed, search-DSL, and multi-pattern regressions.
##########
fe/fe-core/src/main/java/org/apache/doris/qe/SessionVariable.java:
##########
@@ -3513,6 +3515,10 @@ public void
checkAnnIndexCandidateRowsPercentThreshold(String value) {
description = "Enable extended regular expressions, support
look-around zero-width assertions")
public boolean enableExtendedRegex = false;
+ @VarAttrDef.VarAttr(name = ENABLE_HYPERSCAN_FALLBACK, needForward = true,
affectQueryResultInExecution = true,
Review Comment:
[P2] Preserve this policy in load planners
Normal query coordinators receive this value, but load paths replace it with
fresh `TQueryOptions`: both broker-load coordinator builders omit it, and
`NereidsStreamLoadPlanner` does the same for routine and ordinary stream loads.
Because this variable is not session-only, `SET GLOBAL
enable_hyperscan_fallback=false` is persisted and a new stream-load
`ConnectContext` inherits it, yet the planner still sends field 231's default
`true`; broker/routine jobs also never capture the creator's value. A load
filter such as `value_col REGEXP 'a{51}'` consequently falls back and proceeds
instead of returning the strict error, even before replay. Capture/persist the
effective value, populate every load task's options, and cover initial dispatch
plus replay.
--
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]
