Closed jobergum closed 2 years ago
Thoughts on this @arnej27959? Is it possible to have geoLocation as part of the global filter?
my guess is that it would work to add a createFilterSearch method in LocationPreFilterBlueprint in attribute_blueprint_factory.cpp but I'm not sure it that by itself is enough. Can you run the query with debug logging enabled to see what proton.matching.query says about the estimates?
I don't have access to this system where the trace was generated @arnej27959 :=) I'll see if I can reproduce it with a different dataset.
If the LocationPreFilterBlueprint estimates it will hit more than 10% of corpus, it will not be used and ends up as a postfilter only. And the post filter will not be very efficient to use as a global filter. The prefilter will not be very efficient as a global filter either if hits more than 10% of corpus. So to me this looks sane.
I would run the location part of the query only to see how much it returns. Is the estimate very wrong ?
In this trace, the ANN returns 10,000 hits, and LocationPostFilterBlueprint removes 9086 documents and the search combining nearestNeighbor and GeoLocation returns 914 hits.
Result (0 of total 914 hits)
So if the hits returned by ANN are representable, the geo location filter is less than 10% so this looks to be sane from the above explanation about geolocation pre/post filter behavior.
But it might not be super intuitive for end-users how these two operators interact as both have special behavior with regards to post/pre filters :)
No obvious fix, update documentation
Given the following query
The global filtering handling estimates that the geoLocation will match 100% of documents and it ends up as a post-filter after first retrieving 10K from the NN search, and then applying the geoLocation as a post filter.
This can be seen from the following trace. I think this happens because geoLocation has "allow_termwise_eval": 0 ?
Blueprint: