[Search Triage] That will be great, lets see if someone from community is interested in working on this.

[Search Triage] That will be great, lets see if someone from community is interested in working on this.

I'd great to support this feature when the new lucene is released, If @sgup432 agrees.

Also, in addition to this, we need to expose a dynamic setting to update the frequency based caching policy for QueryCache.
As of now, it only caches query when it has seen the same query for 5 times, see here.

Exposing this setting will give us an opportunity to update the value to a lower number, thereby increasing cache utilization if needed.

@sgup432 I attempted to make the frequency value dynamic but failed. While I can override the minFrequencyToCache method, I'm unable to reuse the isCostly method since it's not declared as public.

If we want to make the frequency value dynamic, there seems one way to implement:

• Disregard the "costly" classification.

           cachingPolicy = new UsageTrackingQueryCachingPolicy() {
                @Override
                protected int minFrequencyToCache(Query query) {
                    int minFrequency = this.minFrequency;
                    if (query instanceof BooleanQuery || query instanceof DisjunctionMaxQuery) {
                        --minFrequency;
                    }

                    return Math.max(0, minFrequency);
                }
            };

I'm uncertain whether this is the optimal implementation path or if maintaining the frequency status quo is preferable.

@kkewwei I also believe that is the right/only approach ie passing our implementation of UsageTrackingQueryCachingPolicy along with frequency, which essentially would be defined as a dynamic cluster setting. If you want, you can raise a PR, otherwise I will get to this in few days.

@kkewwei While checking more, I see there are two ways to get around isCostly method

1. Skip it, and have a single frequency value for all types of queries via setting.
2. Define our own way in OpenSearch to define a costly query and provide extension point if needed. We can also try asking lucene community to make it public/extensible in parallel.

Option#2 might be a better way to keep the existing functionality.

@kkewwei While checking more, I see there are two ways to get around isCostly method

1. Skip it, and have a single frequency value for all types of queries via setting.
2. Define our own way in OpenSearch to define a costly query and provide extension point if needed. We can also try asking lucene community to make it public/extensible in parallel.

Option#2 might be a better way to keep the existing functionality.

@sgup432 when definingisCostly, I previously worried that it would not align with lucene, for example, MultiTermQueryConstantScoreWrapper and MultiTermQueryConstantScoreWrapper are not public, making it inaccessible in OpenSearch.

However, I now realize we can simply check the class name instead of directly referencing MultiTermQueryConstantScoreWrapper and MultiTermQueryConstantScoreWrapper.

If you think it's feasible, I'll do it this way.

Yeah I personally think that having a custom caching policy for OpenSearch should be fine, given that lucene doesn't give the desired extensibility at this point.