On Sun, Oct 4, 2009 at 8:15 PM, Steve Conover <scono...@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 <yo...@lucidimagination.com> > wrote: >> On Sat, Oct 3, 2009 at 11:44 AM, Steve Conover <scono...@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 >> >
