-
Notifications
You must be signed in to change notification settings - Fork 83
Optimise facets indexing #590
Conversation
a2c8bdf to
5728619
Compare
|
Note: I'm putting this PR back into draft status as I don't think the improvement is good enough. The problem is that after adding just one document, we need to iterate over the whole database and perform a ton of bitmap operations, which is very slow. Ideally, the algorithm should be incremental and modify the database in-place instead of clearing it and rebuilding it from scratch. I am starting to think about what a proper solution will be and will update this PR later. |
|
After looking a bit more into it, I realised there is a problem with the current structure of As a result, adding an element at level 0 automatically invalidates all its parents and its parents' successors. That means the minimum complexity of adding an element is I think this could be solved by using strings directly instead of indices as keys, like this: But as explained in But I suspect it would make it difficult to use and/or create this structure. |
|
After thinking about it more, I think this PR should be reviewed as is for now, because:
|
Write the algorithm once for both numbers and strings
5728619 to
3968790
Compare
6e0fec6 to
6cc9757
Compare
Kerollmops
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much!
bors merge
|
Build succeeded: |
Pull Request
What does this PR do?
Fixes #589
Notes
I added documentation for the whole module which attempts to explain the shape of the databases and their purpose. However, I realise there is already some documentation about this, so I am not sure if we want to keep it.
Benchmarks
We get a ~1.15x speed up on the geo_point benchmark.