lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2780) optimize spantermquery
Date Fri, 26 Nov 2010 10:56:13 GMT


Michael McCandless commented on LUCENE-2780:

Looks good Robert!  It's a sneaky trap.  Maybe add a comment to createWeight explaining that
this is only used when a "normal" (non-span) Query embeds a SpanTermQuery?

Someday we need to merge Span* back into the "normal" queries.

> optimize spantermquery
> ----------------------
>                 Key: LUCENE-2780
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Robert Muir
>             Fix For: 3.1, 4.0
>         Attachments: LUCENE-2780.patch
> Looking at
> I saw a user building DisjunctionMaxQuery / BooleanQuery with SpanTermQuerys.
> I wonder if users know that doing this is much slower than just using TermQuery?
> I agree it makes little sense to use SpanTermQuery if you arent going to use it inside
a SpanNear etc,
> but on the other hand, I think its a little non-intuitive that it wouldnt be just as
fast in a case like this.
> I could see this complicating queryparsing etc for users that want to sometimes use positions
> SpanTermQuery is the same as TermQuery, except tf is computed as (#of spans * sloppyFreq(spanLength)
> For this case, #ofspans = tf and spanLength for a single term is always 1.
> Maybe we should optimize SpanTermQuery to return TermScorer, with just this special tf
> This would avoid reading positions for anyone that does this.

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message