lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <yo...@lucidimagination.com>
Subject Re: is it possible to speed up this query?
Date Mon, 05 Oct 2009 00:43:33 GMT
On Sun, Oct 4, 2009 at 8:15 PM, Steve Conover <sconover@gmail.com> wrote:
> Can't/won't...this is one part of a set of criteria, and those
> criteria can be pretty arbitrarily changed.  I couldn't - with
> confidence - extract this part without possibly compromising the
> correctness of the result.
>
> Thanks for the suggestion though...is there anything else to be done?
> Anything I could be specifically caching?

Lowering the precisionStep of the trie field could help.  With a
precisionStep of 8, there would be 256 top-level terms to step over.
If you lowered it to 6, it would cut it to 64 or 4 would cut it to 16.

The fastest would be to index a separate field to indicate presence or
absence of your field.
So instead of
myfield:[* TO *]
  use
field_present:myfield
  or
-field_absent:myfield

-Yonik
http://www.lucidimagination.com


> Regards,
> Steve
>
> On Sat, Oct 3, 2009 at 9:07 AM, Yonik Seeley <yonik@lucidimagination.com> wrote:
>> On Sat, Oct 3, 2009 at 11:44 AM, Steve Conover <sconover@gmail.com> wrote:
>>> Hi,
>>>
>>> I have a query that's taking about 120ms to run that I'd like to try
>>> to reduce if possible.  The key element that seems to be at the root
>>> of about 100ms of the delay is a "not null" criterion (it happens to
>>> be a Long field), i.e.
>>>
>>> foo:[* TO *]
>>>
>>> I've tried converting to trie ranges and that hasn't helped - are
>>> there any other tricks around accomplishing "not null" that would turn
>>> the query around faster?
>>
>> Could you pull it out as a filter?   fq=foo:[* TO *]
>>
>> -Yonik
>> http://www.lucidimagination.com
>>
>

Mime
View raw message