Hello Jason,

why you see different behavior for SortedIntDocSet vs. BitDocSet


This is the part I'm confused about as well, I'm not sure if the native
implementation has any differences for those 2 classes, but this is what I
see when I run through the debugger.

How are you tracking, or how did you notice the queryResultCache
> misses initially,


We have a tracking system that logs all the "expensive" requests. Manually
replaying some of the requests showed no Qtime improvement after few
refreshes

Best,
Yue


On Tue, Dec 2, 2025 at 9:15 AM Jason Gerlowski <[email protected]>
wrote:

> Hi Yue,
>
> Interesting theory!
>
> If the problem is due to how DocSet objects handle hashCode(), do you
> have any guess why you see different behavior for SortedIntDocSet vs.
> BitDocSet?  At a glance they both inherit the same "hashCode"
> implementation from Object so I'd naively expect both the positive and
> negative filter case to behave similarly, unless I'm missing
> something?
>
> How are you tracking, or how did you notice the queryResultCache
> misses initially, if I may ask?
>
> Best,
>
> Jason
>
> On Tue, Nov 25, 2025 at 6:16 PM Yue Yu <[email protected]> wrote:
> >
> > Hello,
> >
> > I have encountered an issue that the KnnFloatVectorQuery could not get
> the
> > superset from queryResultCache when I have negative filters in the
> request.
> > For example, *fq=-some_field:value*. But with positive fq it works fine:
> > *fq=**some_field**:value*
> >
> > Here is my testing environment:
> > Solr 9.5.0
> > openjdk 21.0.9 2025-10-21
> > OpenJDK Runtime Environment (build 21.0.9+10-Ubuntu-122.04)
> > OpenJDK 64-Bit Server VM (build 21.0.9+10-Ubuntu-122.04, mixed mode,
> > sharing)
> >
> > I think it's probably because of the hashCode() function in DocSetQuery
> > class. The query result cache uses QueryResultKey which relies on the
> > query.hashCode() value, however, AbstractKnnVectorQuery's hashcode
> function
> > uses the hashcode values from the vector field, k, and the prefilter
> query:
> >
> > @Override
> > public int hashCode() {
> >   return Objects.hash(field, k, filter);
> > }
> >
> >
> > The prefilter queries are converted to DocSetQuery object whose
> > underlying DocSet object may not implement the hashCode() function, such
> > as BitDocSet or SortedIntDocSet, hence KnnFloatVectorQuery.hashcode()
> value
> > may not be consistent, depending on the JVM. In my test
> > setting, SortedIntDocSet(positive fq) seems getting consistent hashcode
> > value but not BitDocSet(negative fq). I'm wondering if anyone else has
> seen
> > this issue?
> >
> > Thanks in advance,
> > Yue
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to