Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <690348848.1246033629778.JavaMail.jira@brutus>
Date: Fri, 26 Jun 2009 09:27:09 -0700 (PDT)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1461) Cached filter for a single term
 field
In-Reply-To: <1103206257.1227057224301.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724605#action_12724605 ] 

Michael McCandless commented on LUCENE-1461:
--------------------------------------------

bq. This is not only because of the deleted docs. Its also because the while loops are no longer hard coded with bounds, so there is an additional method call to check if something is a hit. The linear scan makes this also very costly. But without it, the code is unmaintainable (with all problems like copy/paste errors) and so on. It is almost 6 times the same code.

The tradeoff of code ugliness vs performance is always an "interesting" one, but here we lost 2X performance :(  Maybe we leave this to future source code specialization.

bq. In my opinion, in most cases TrieRange is better (and with Payloads, too).

Since, with the 2X slowdown, and with the linear-scan impl, this filter is not faster than trie... should we even bother?  It's going to confuse users having two ways to do numeric filtering, and, trie seems to be best across the board anyway?  Are there any times that this filter is better than trie?

bq.   So I keeps this filter how it is for the beginning.

OK, you mean leave this filter as only doing text (term) ranges?  OK, that sounds good.

> Cached filter for a single term field
> -------------------------------------
>
>                 Key: LUCENE-1461
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1461
>             Project: Lucene - Java
>          Issue Type: New Feature
>            Reporter: Tim Sturge
>            Assignee: Uwe Schindler
>             Fix For: 2.9
>
>         Attachments: DisjointMultiFilter.java, FieldCacheRangeFilter.patch, LUCENE-1461.patch, LUCENE-1461.patch, LUCENE-1461.patch, LUCENE-1461.patch, LUCENE-1461.patch, LUCENE-1461.patch, LUCENE-1461a.patch, LUCENE-1461b.patch, LUCENE-1461c.patch, PerfTest.java, RangeMultiFilter.java, RangeMultiFilter.java, TermMultiFilter.java, TestFieldCacheRangeFilter.patch
>
>
> These classes implement inexpensive range filtering over a field containing a single term. They do this by building an integer array of term numbers (storing the term->number mapping in a TreeMap) and then implementing a fast integer comparison based DocSetIdIterator.
> This code is currently being used to do age range filtering, but could also be used to do other date filtering or in any application where there need to be multiple filters based on the same single term field. I have an untested implementation of single term filtering and have considered but not yet implemented term set filtering (useful for location based searches) as well. 
> The code here is fairly rough; it works but lacks javadocs and toString() and hashCode() methods etc. I'm posting it here to discover if there is other interest in this feature; I don't mind fixing it up but would hate to go to the effort if it's not going to make it into Lucene.

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org