[
https://issues.apache.org/jira/browse/LUCENE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220259#comment-16220259
]
Alan Woodward commented on LUCENE-8017:
---------------------------------------
The easiest solution is to just exclude the Function queries from the cache,
but this seems a shame as you could easily have quite complex functions that
are index-independent, and therefore ideal for cacheing. It also ends up being
kind of hacky as they're not in core, so we end up using introspection to
determine class names.
Another option is to add an isCacheable() method to Query, or alternatively a
cacheCost() method - the latter I quite like, as it means that different cache
implementations can choose whether or not to cache in a more fine-grained
manner. Queries can then determine for themselves if they can be cached, so
for example FunctionMatchQuery can delegate through to its DoubleValuesSource
to determine whether or not it's index independent. However, it does mean
increasing the API surface.
> FunctionRangeQuery and FunctionMatchQuery can pollute the QueryCache
> --------------------------------------------------------------------
>
> Key: LUCENE-8017
> URL: https://issues.apache.org/jira/browse/LUCENE-8017
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Alan Woodward
> Assignee: Alan Woodward
>
> The QueryCache assumes that queries will return the same set of documents
> when run over the same segment, independent of all other segments held by the
> parent IndexSearcher. However, both FunctionRangeQuery and
> FunctionMatchQuery can select hits based on score, which depend on term
> statistics over the whole index, and could therefore theoretically return
> different result sets on a given segment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
