rajat315315 commented on issue #16429: URL: https://github.com/apache/lucene/issues/16429#issuecomment-5113132655
Thanks for the feedback @jpountz! Reusing the index-time DocValues skip index makes total sense to avoid extra memory caching. I ran a JMH benchmark (`ScriptWANDBlockCacheBenchmark`) on a 10M document index to compare the pruning efficiency of different DocValues block sizes (4096, 1024, 512, 128): | Block Size | Execution Strategy | Throughput (ops/sec) | Speedup vs Baseline | Speedup vs 4096 Block Size | | :---: | :--- | :---: | :---: | :---: | | **N/A** | Baseline Unpruned Script Query | 39.41 ops/sec | 1.00x | 1.00x | | **4096 Docs** | DocValues Skip Index WAND | 43.61 ops/sec | +10.7% | 1.00x (Current Default) | | **1024 Docs** | DocValues Skip Index WAND | 76.90 ops/sec | +95.2% | 1.76x Faster | | **512 Docs** | DocValues Skip Index WAND | 117.09 ops/sec | +197.1% | 2.68x Faster | | **128 Docs** | DocValues Skip Index WAND | 204.31 ops/sec | +418.5% (5.18x) | **4.68x FASTER than 4096** | The data confirms your intuition: 4,096 docs per block is often too coarse for efficient skipping (+10.7% gain), because outlier hits inflate the block max score. Lowering the block size to 128 (or 512) gives 4.68x higher QPS because WAND can skip non-competitive blocks much more precisely. I will start by using the existing DocValues skip index as you suggested, and then propose a configurable/smaller block size option for high-throughput WAND skipping! Below is my benchmark script that I have used to generate above results: [ScriptWANDBlockCacheBenchmark.java](https://github.com/user-attachments/files/30489846/ScriptWANDBlockCacheBenchmark.java) -- 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]
