Hi Kumar,

According to an existing test this should work:
https://github.com/apache/solr/blob/ac3d349dac530cf1001d5113fc21b0fd641cc9d5/solr/core/src/test/org/apache/solr/search/QueryEqualityTest.java#L1494

I noticed we're resolving the preFilter to a DocSetQuery
in AbstractVectorQParserBase
https://github.com/apache/solr/blob/ac3d349dac530cf1001d5113fc21b0fd641cc9d5/solr/core/src/java/org/apache/solr/search/neural/AbstractVectorQParserBase.java#L149

This DocSetQuery wraps a DocSet. The Solr DocSet implementations don't seem
to implement a custom equals/hashCode,
so they are only equal when the same instance is returned, which is the
case if they are returned from the filter cache.

Could there be a reason for findable:true not being resolved by the
filterCache in your case?

Regards
Matthias


On Thu, Mar 6, 2025 at 1:18 PM kumar gaurav <kg2...@gmail.com> wrote:

> Hi All
>
> We are using bool query parser for hybrid search with
> vectorSimilarty parser as a clause.
>
> We got the issue that Boolean Query parser is not caching vectorSimilarity
> result in Query result cache *in case preFilter is used *which is a culprit
> for performance impact. We got Same behaviour with the knn parser as well.
>
> We debugged it in Solr code and found that if pre-filter is used then
> BooleanQuery.hashcode() is calculating different values even if it is the
> same query requests. If we remove preFilter then the result cache works.
>
> Solr Query
> {
>     "params": {
>         "spellcheck": "true",
>         "start": "0",
>         "rows": "10",
>         "q": "{!bool should=$vectorQuery}",
>         "defType": "lucene",
>         "vector":
>
> "[-0.045949627,-0.027026573,-0.019423958,0.03261444,-0.009923472,0.017075274,-0.018088214,0.09207735,0.004494225,0.10026992...]",
>         "preFilter": [
>             "findable:true",
>         ],
>         "vectorQuery": "{!vectorSimilarity f=vector_1024$embeddings
> minReturn=0.74 minTraverse=0.72 preFilter=$preFilter v=$vector}"
>     }
> }
>
> *Is it a bug of Solr which is in line to be fixed in future ? *
>
> *A lot of thanks in advance. Hoping reply from Alessandro Benedetti :). *
>
>
>
> --
> Thanks & Regards
> Kumar Gaurav
> +91 9313529899
>

Reply via email to