perf: optimize re filter - #484
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #484 +/- ##
==========================================
+ Coverage 71.19% 71.31% +0.12%
==========================================
Files 232 232
Lines 18492 18622 +130
==========================================
+ Hits 13165 13281 +116
- Misses 4344 4354 +10
- Partials 983 987 +4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@seqbenchbot start search-regular main 'transaction_id:re("tx-cafe.*")' --cold --duration=5m |
|
Nice, @dkharms Started benchmark Show details
I'll post the statistics here once it finishes. Here is a list of helpful links: Have a great time! |
|
Nice, @dkharms Benchmark Show summary
Compare it against another run with |
|
@seqbenchbot start search-regular 355-re-optimization 'transaction_id:re("tx-cafe.*")' --cold --duration=5m |
|
Nice, @dkharms Started benchmark Show details
I'll post the statistics here once it finishes. Here is a list of helpful links: Have a great time! |
|
Nice, @dkharms Benchmark Show summary
Compare it against another run with |
| // NOTE(dkharms): We do not allow overriding of case-sensitivity | ||
| // in case if search is case-insensitive. | ||
| // | ||
| // This way `re` filter works consistently with how `keyword` | ||
| // and `text` search behave. | ||
| overridable := config.CaseSensitive | ||
| if !overridable && hasCaseSensitivityOverride(re) { | ||
| return nil, fmt.Errorf( | ||
| "store is configured for case-insensitive search: " + | ||
| "you cannot override this option", | ||
| ) | ||
| } | ||
|
|
||
| lex.Next() | ||
| // NOTE(dkharms): Again, if store works in case-insensitive mode | ||
| // we simulate behaviour of `keyword` and `text` indexes. | ||
| // Should we really do this? | ||
| if !overridable { | ||
| expr = strings.ToLower(expr) | ||
| } |
There was a problem hiding this comment.
This decision is debatable.
7b43684 to
ecad208
Compare
Description
Previously the
refilter compiled the user's regular expression and ran a fullregexp.Matchagainst every token in the index.This change parses the regex AST (via
regexp/syntax) at query-parse time and extracts the constant literal fragments it must contain: a prefix, a suffix, and any literal substrings in the middle.On top of literal pre-filtering, when the token list is ordered we use the extracted prefix to narrow the search range with a binary search, so we only scan the contiguous slice of tokens that can possibly match the prefix instead of the whole index.
In overall I see a huge improvement in search latencies over different queries (3x-150x).
Take a look at results:
Show results
mean (ms)stddev (ms)p(50) (ms)p(95) (ms)p(99) (ms)iterations365.25113.50-68.93%19.298.19-57.58%369.00111.00-69.92%377.50120.00-68.21%377.50120.00-68.21%4.004.000.00%175.851.20-99.32%48.880.52-98.93%156.001.00-99.36%255.002.00-99.22%298.502.50-99.16%20.0020.000.00%1307.75246.50-81.15%121.2631.08-74.37%1240.00244.00-80.32%1394.50266.50-80.89%1394.50266.50-80.89%4.004.000.00%911.752.00-99.78%25.920.00-100.00%904.002.00-99.78%956.002.00-99.79%957.502.00-99.79%20.0020.000.00%1233.50218.50-82.29%16.7811.96-28.75%1227.00216.00-82.40%1247.00226.50-81.84%1247.00226.50-81.84%4.004.000.00%919.902.05-99.78%34.270.39-98.85%913.002.00-99.78%995.003.00-99.70%998.503.00-99.70%20.0020.000.00%1227.50421.25-65.68%17.99101.20+462.50%1225.00370.00-69.80%1241.00473.50-61.85%1241.00473.50-61.85%4.004.000.00%995.7534.45-96.54%116.476.30-94.59%964.0031.00-96.78%1229.0044.00-96.42%1311.0047.00-96.41%20.0020.000.00%Part of #355 (There is some unfinished business still, we will get back to it later)
If you have used LLM/AI assistance please provide model name and full prompt: