lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-80) negative filter queries
Date Tue, 23 Jan 2007 01:21:49 GMT

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

Hoss Man commented on SOLR-80:
------------------------------

i think there may be a caching bugwith this... if you load up the example schema, populate
it, and then stop/start the port so all of the caches are empty, and hit this URL...

http://localhost:8983/solr/select/?q=cat%3Aelectronics&version=2.2&start=0&fl=score,name&fq=samsung

you see that the lookup/insert/size for both the queryResultsCache and filterCaches are 1
(as expected)

if you then hit this URL...

http://localhost:8983/solr/select/?q=cat%3Aelectronics&version=2.2&start=0&fl=score,name&fq=-samsung

the queryResultCache changes predictably to a size of 2 (because the filters are part of the
cache key) but the size of the filterCache has also grown to 2 ... which doesn't make sense
since the patch is suppose to be caching the inverse of negative queries (fq=samsung and fq=-samsung
should be a cahce hit right?)

if you stop/start the port and only hit this URL...

http://localhost:8983/solr/select/?q=cat%3Aelectronics&version=2.2&start=0&fl=score,name&fq=-samsung

...you'll see that the filterCache gets 2 lookups, and 2 insertions.


I wouldn't think this is wrong, except that the patch explicitly says "// cache negative queries
as positive"



> negative filter queries
> -----------------------
>
>                 Key: SOLR-80
>                 URL: https://issues.apache.org/jira/browse/SOLR-80
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>            Reporter: Yonik Seeley
>         Attachments: negative_filters.patch, negative_filters.patch
>
>
> There is a need for negative filter queries to avoid long filter generation times and
large caching requirements.
> Currently, if someone wants to filter out a small number of documents, they must specify
the complete set of documents to express those negative conditions against.  
> q=foo&fq=id:[* TO *] -id:101
> In this example, to filter out a single document, the complete set of documents (minus
one) is generated, and a large bitset is cached.  You could also add the restriction to the
main query, but that doesn't work with the dismax handler which doesn't have a facility for
this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message