Confirmed users
574
edits
DXR Storages: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 17: | Line 17: | ||
* Line-based searching without icky hacks ([https://github.com/elasticsearch/elasticsearch/issues/3022 nested queries are being a pain in the neck], but parent-child ones seem like a workable solution.) | * Line-based searching without icky hacks ([https://github.com/elasticsearch/elasticsearch/issues/3022 nested queries are being a pain in the neck], but parent-child ones seem like a workable solution.) | ||
* Caching of intermediate filter results. (It will transparently store the set of, say, all *.cpp files as a bitmap for quick set operations later. This means that common compound queries will likely be much faster than in any RDBMS.) | * Caching of intermediate filter results. (It will transparently store the set of, say, all *.cpp files as a bitmap for quick set operations later. This means that common compound queries will likely be much faster than in any RDBMS.) | ||
* Suggesters for "did you mean" and autocomplete | * Suggesters for "did you mean" and autocomplete | ||
* Sparse attribute storage, which could come in handy for supporting new languages | * Sparse attribute storage, which could come in handy for supporting new languages | ||
* Extreme flexibility of indexing: index whatever chars we want, index them any number of ways (case-sensitive or not), and entirely too much more | |||
Nice to have: | |||
* Parallelization of even single queries | |||
* Redundancy | |||
* Scoring | * Scoring | ||
=== Challenge: Fast Regex Matching === | === Challenge: Fast Regex Matching === | ||