[
https://issues.apache.org/jira/browse/SOLR-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259150#comment-14259150
]
Alexander S. edited comment on SOLR-6494 at 12/26/14 5:27 PM:
--------------------------------------------------------------
Just an idea, but what if Solr detecting that the filter does use date rages
like [* TO 2014-09-08T23:59:59Z] (or probably any ranges where cache is not
very efficient), and if there are other simpler filters in the query, will
apply such range filters at last? And probably to already fetched results as a
post filter? And probably avoid caching for this filter? That sounds like a
good optimization to me. This will avoid losing of more useful filters from the
cache, increase warming speed and which is the most important — increase the
search speed.
Like in the case above, if you have 200m of docs, but only 12k with
type:AwardNomination, and query has 2 filters where one with a date range. Solr
definitely can detect this and do the right thing instead of simply looping
through all 200m documents with this cache-inefficient filter. Could this be at
least considered as a wish and reopened?
[~erickerickson] [~hossman]
Best,
Alex
was (Author: aheaven):
Just an idea, but what if Solr detecting that the filter does use date rages
like [* TO 2014-09-08T23:59:59Z] (or probably any ranges where cache is not
very efficient), and if there are other simpler filters in the query, will
apply such range filters at last? And probably to already fetched results as a
post filter? And probably avoid caching for this filter? That sounds like a
good optimization to me. This will avoid losing of more useful filters from the
cache, increase warming speed and which is the most important — increase the
search speed.
Like in the case above, if you have 200m of docs, but only 12k with
type:AwardNomination, and query has 2 filters, one with a date range, Solr
definitely can detect this and do the right thing instead simply loop through
all 200m documents with this cache-inefficient filter. Could this be at least
considered as a wish and reopened?
[~erickerickson] [~hossman]
Best,
Alex
> Query filters applied in a wrong order
> --------------------------------------
>
> Key: SOLR-6494
> URL: https://issues.apache.org/jira/browse/SOLR-6494
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.8.1
> Reporter: Alexander S.
>
> This query:
> {code}
> {
> fq: ["type:Award::Nomination"],
> sort: "score desc",
> start: 0,
> rows: 20,
> q: "*:*"
> }
> {code}
> takes just a few milliseconds, but this one:
> {code}
> {
> fq: [
> "type:Award::Nomination",
> "created_at_d:[* TO 2014-09-08T23:59:59Z]"
> ],
> sort: "score desc",
> start: 0,
> rows: 20,
> q: "*:*"
> }
> {code}
> takes almost 15 seconds.
> I have just ≈12k of documents with type "Award::Nomination", but around half
> a billion with created_at_d field set. And it seems Solr applies the
> created_at_d filter first going through all documents where this field is
> set, which is not very smart.
> I think if it can't do anything better than applying filters in the alphabet
> order it should apply them in the order they were received.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
