gf2121 commented on issue #12725: URL: https://github.com/apache/lucene/issues/12725#issuecomment-1798007152
> do we have any numbers if it actually helps applying deletes? I made a naive benchmark comparing `seekCeil` and `seekExact` when deleting terms on a field with bloom filter, result shows `seekExact` style ~9% faster in average. (All terms are 16 bytes UUID) <!--StartFragment--><byte-sheet-html-origin data-id="1699344140551" data-version="4" data-is-embed="false" data-grid-line-hidden="false" data-importRangeRawData-spreadSource="https://bytedance.feishu.cn/sheets/Jwjzs3FdXhFbVwtfADJc6L8rnCb"; data-importRangeRawData-range="'Sheet1'!A1:D12"> round | seekCeil(ms) | candidate(ms) | diff -- | -- | -- | -- 1 | 46211 | 42783 | -7% 2 | 44641 | 40698 | -9% 3 | 44462 | 43471 | -2% 4 | 47059 | 43842 | -7% 5 | 45049 | 43609 | -3% 6 | 49529 | 40953 | -17% 7 | 44707 | 41498 | -7% 8 | 45732 | 40785 | -11% 9 | 45396 | 41321 | -9% 10 | 48759 | 40760 | -16% avg | 46154.5 | 41972 | -9% </byte-sheet-html-origin><!--EndFragment--> > wild idea but would it make sense to build an automaton off these terms and intersect it? We could reuse it for multiple segments? I am not sure how big the costs are for that but it would potentially in a codec agnostic way? This sounds great. I think intersecting with automation can not take advantage of bloom filter too. So it should be a competitive approach comparing to `seekExact` or `seekCeil` ? I'd like to give it a try. -- 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: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
