You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mikhail Khludnev (JIRA)" <ji...@apache.org> on 2013/07/31 12:53:49 UTC

[jira] [Comment Edited] (SOLR-5093) Rewrite field:* to use the filter cache

    [ https://issues.apache.org/jira/browse/SOLR-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725094#comment-13725094 ] 

Mikhail Khludnev edited comment on SOLR-5093 at 7/31/13 10:51 AM:
------------------------------------------------------------------

I agree with vetoes. 
but in a rare cases users need {noformat}q=bee:blah OR pp:*{noformat}  there is also a jira to handle fq disjunction like {noformat}fq=foo:bar OR foo:baz{noformat}. We can deliver simple qparser and use it like
{noformat}q=bee:blah OR _query_:"{!fq}foo:bar" OR _query_:"{!fq}foo:bar"{noformat} 
it keeps syntax crazy enough. that's great. 
Will you accept it ?

Afterwards, we can allow BS in Solr to handle filters disjunction efficiently. 
                
      was (Author: mkhludnev):
    I agree with vetoes. 
but in a rare cases users need q=bee:blah *OR* pp:\* there is also a jira to handle fq disjunction like fq=foo:bar OR foo:baz. We can deliver simple qparser and use it like
q=bee:blah OR _query_:"{!fq}foo:bar" OR _query_:"{!fq}foo:bar"
it keeps syntax crazy enough. that's great. 
Do you like to accept it ?

Afterwards, we can allow BS in Solr to handle filters disjunction efficiently. 
                  
> Rewrite field:* to use the filter cache
> ---------------------------------------
>
>                 Key: SOLR-5093
>                 URL: https://issues.apache.org/jira/browse/SOLR-5093
>             Project: Solr
>          Issue Type: New Feature
>          Components: query parsers
>            Reporter: David Smiley
>
> Sometimes people writes a query including something like {{field:*}} which matches all documents that have an indexed value in that field.  That can be particularly expensive for tokenized text, numeric, and spatial fields.  The expert advise is to index a separate boolean field that is used in place of these query clauses, but that's annoying to do and it can take users a while to realize that's what they need to do.
> I propose that Solr's query parser rewrite such queries to return a query backed by Solr's filter cache.  The underlying query happens once (and it's slow this time) and then it's cached after which it's super-fast to reuse.  Unfortunately Solr's filter cache is currently index global, not per-segment; that's being handled in a separate issue.  
> Related to this, it may be worth considering if Solr should behind the scenes index a field that records which fields have indexed values, and then it could use this indexed data to power these queries so they are always fast to execute.  Likewise, {{\[\* TO \*\]}} open-ended range queries could similarly use this.
> For an example of how a user bumped into this, see:
> http://lucene.472066.n3.nabble.com/Performance-question-on-Spatial-Search-tt4081150.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org