Performance Degradation in Solr When Using OR with frange in fq

[Daxesh Parmar <da...@gmail.com>]

Hi Team,

High Query Time in Solr When Using OR with frange in fq

We are experiencing high query times in Solr when using an fq filter that
combines an OR condition with frange. The response time significantly
increases compared to queries that do not use this combination.

Query Example
fq={!cache=false tag=prm}field:value OR {!frange l=1 u=1 v=$funcQuery}

Here, $funcQuery is a function query that retrieves documents dynamically
based on dynamic parameters.

Observations
1) When we use just {!frange l=1 u=1 v=$funcQuery}, the query executes
quickly[20ms].
2) When we use {!cache=false tag=prm}field: value alone, the query is also
fast, its working fast with the AND operator.
3) However, when combining both with OR, the query time increases
significantly [700ms].
4) The dataset is relatively large, but other queries with similar
complexity run efficiently.

Question
1) Why does the OR operation with frange cause a significant increase in
query time?
2) Are there any optimizations or alternative query structures that could
improve performance?
3) Would it help to restructure how function queries and filters are
applied in this case?
4) Is there any alternative for frange for this use case because in our use
case, this cannot be done at index time because the function parameters
change very frequently?

Any insights or suggestions would be greatly appreciated.

Re: Performance Degradation in Solr When Using OR with frange in fq

[David Smiley <ds...@apache.org>]

Ideally, after the user created the JIRA issue, it would be shared in this
thread.  Here it is:
https://issues.apache.org/jira/browse/SOLR-17699
(fix for 9.9)

Nice response Hoss, particularly sharing the "filter" trick, which may be
useful here.

On Wed, Mar 19, 2025 at 2:18 PM Chris Hostetter <ho...@fucit.org>
wrote:

>
> : We are experiencing high query times in Solr when using an fq filter that
> : combines an OR condition with frange. The response time significantly
> : increases compared to queries that do not use this combination.
> :
> : Query Example
> : fq={!cache=false tag=prm}field:value OR {!frange l=1 u=1 v=$funcQuery}
>
> The first thing i want to make sure you understand is that the {!...}
> syntax is prefix based, so {!cache=false tag=prm} applies to the *entire*
> "fq" param -- not just the "field:value" boolean clause -- i want to
> clarify that because the way you describe breakign the query down implies
> you think otherwise...
>
> : Observations
> : 1) When we use just {!frange l=1 u=1 v=$funcQuery}, the query executes
> : quickly[20ms].
>
> Details matter -- you say "when we use just ..." the frange portion it's
> quick -- but you're not clarifying *how* you use the frange portion by
> itself.
>
> If you mean a request with 'fq={!frange l=1 u=1 v=$funcQuery}' is quick,
> that's likely because it winds up being slow the first time, and
> then cached in the filterCache for very fast subsequent use.
>
> : Question
> : 1) Why does the OR operation with frange cause a significant increase in
> : query time?
>
> The way an frange query works is that it scans every document in the index
> to compute the function value, and then checks if it is in range.
>
> In general, when Lucnee/Solr execute a two clause boolean "AND" query,
> the searcher can tell individual clauses to "skip ahead" based on the
> current match point from the other AND clause
>
> So in the case of "X:Y AND {!frange...}" where X:Y only matches a small
> subset of the index, the frange doesn't have to be computed for every
> document in the index, it gets to skip ahead to the first match of "X:Y"
> and then skip ahead to the second match of "X:Y", etc...
>
> With "X:Y OR {!frange...}" it still has compute the function for every
> document in the index ... and when you combine that with the "cache=false"
> (on the entire "fq")
>
> : 2) Are there any optimizations or alternative query structures that could
> : improve performance?
>
> you can use the special (and slightly odd) "filter()" syntax in the
> default parser to say that a particular boolean clause should be cached as
> non-scoring clause (and that cache hit will be re-used even when using in
> other boolean queries...
>
> fq=X:Y OR filter({!frange...})
> fq=X:Z OR filter({!frange...}) // the frange will be a filterCache hit
>
>
> -Hoss
> http://www.lucidworks.com/
>

Re: Performance Degradation in Solr When Using OR with frange in fq

[Chris Hostetter <ho...@fucit.org>]

: We are experiencing high query times in Solr when using an fq filter that
: combines an OR condition with frange. The response time significantly
: increases compared to queries that do not use this combination.
: 
: Query Example
: fq={!cache=false tag=prm}field:value OR {!frange l=1 u=1 v=$funcQuery}

The first thing i want to make sure you understand is that the {!...} 
syntax is prefix based, so {!cache=false tag=prm} applies to the *entire* 
"fq" param -- not just the "field:value" boolean clause -- i want to 
clarify that because the way you describe breakign the query down implies 
you think otherwise...

: Observations
: 1) When we use just {!frange l=1 u=1 v=$funcQuery}, the query executes
: quickly[20ms].

Details matter -- you say "when we use just ..." the frange portion it's 
quick -- but you're not clarifying *how* you use the frange portion by 
itself.

If you mean a request with 'fq={!frange l=1 u=1 v=$funcQuery}' is quick, 
that's likely because it winds up being slow the first time, and 
then cached in the filterCache for very fast subsequent use.

: Question
: 1) Why does the OR operation with frange cause a significant increase in
: query time?

The way an frange query works is that it scans every document in the index 
to compute the function value, and then checks if it is in range.

In general, when Lucnee/Solr execute a two clause boolean "AND" query, 
the searcher can tell individual clauses to "skip ahead" based on the 
current match point from the other AND clause

So in the case of "X:Y AND {!frange...}" where X:Y only matches a small 
subset of the index, the frange doesn't have to be computed for every 
document in the index, it gets to skip ahead to the first match of "X:Y" 
and then skip ahead to the second match of "X:Y", etc...

With "X:Y OR {!frange...}" it still has compute the function for every 
document in the index ... and when you combine that with the "cache=false" 
(on the entire "fq") 

: 2) Are there any optimizations or alternative query structures that could
: improve performance?

you can use the special (and slightly odd) "filter()" syntax in the 
default parser to say that a particular boolean clause should be cached as 
non-scoring clause (and that cache hit will be re-used even when using in 
other boolean queries...

fq=X:Y OR filter({!frange...})
fq=X:Z OR filter({!frange...}) // the frange will be a filterCache hit


-Hoss
http://www.lucidworks.com/

Re: Performance Degradation in Solr When Using OR with frange in fq

[Houston Putman <ho...@apache.org>]

Please do not cross-list emails. Choose either Users or Dev.

Also this is the third time we have received a variant of this email, so
please stop sending it.
Someone will respond.

- Houston

On Wed, Mar 12, 2025 at 10:12 AM Daxesh Parmar <da...@gmail.com>
wrote:

> Hi Team,
>
> High Query Time in Solr When Using OR with frange in fq
>
> We are experiencing high query times in Solr when using an fq filter that
> combines an OR condition with frange. The response time significantly
> increases compared to queries that do not use this combination.
>
> Query Example
> fq={!cache=false tag=prm}field:value OR {!frange l=1 u=1 v=$funcQuery}
>
> Here, $funcQuery is a function query that retrieves documents dynamically
> based on dynamic parameters.
>
> Observations
> 1) When we use just {!frange l=1 u=1 v=$funcQuery}, the query executes
> quickly[20ms].
> 2) When we use {!cache=false tag=prm}field: value alone, the query is also
> fast, its working fast with the AND operator.
> 3) However, when combining both with OR, the query time increases
> significantly [700ms].
> 4) The dataset is relatively large, but other queries with similar
> complexity run efficiently.
>
> Question
> 1) Why does the OR operation with frange cause a significant increase in
> query time?
> 2) Are there any optimizations or alternative query structures that could
> improve performance?
> 3) Would it help to restructure how function queries and filters are
> applied in this case?
> 4) Is there any alternative for frange for this use case because in our use
> case, this cannot be done at index time because the function parameters
> change very frequently?
>
> Any insights or suggestions would be greatly appreciated.
>