Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 1066 invoked from network); 29 Mar 2007 15:00:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Mar 2007 15:00:54 -0000 Received: (qmail 50563 invoked by uid 500); 29 Mar 2007 15:00:54 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 50531 invoked by uid 500); 29 Mar 2007 15:00:54 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 50520 invoked by uid 99); 29 Mar 2007 15:00:54 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2007 08:00:54 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of peterlkeegan@gmail.com designates 64.233.162.231 as permitted sender) Received: from [64.233.162.231] (HELO nz-out-0506.google.com) (64.233.162.231) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2007 08:00:46 -0700 Received: by nz-out-0506.google.com with SMTP id i1so154923nzh for ; Thu, 29 Mar 2007 08:00:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PX8ZrD+95uMsiNhjLpT4ZUGKf+boA6LqYOoL2muhCMsvC5WS1408jTwfZLw/1nmBFKyWFW6AJk5HMJ0m7LW4Uta8Q+oVBEtW07Yf3HSSj/PKXf+nqfs4bCa6zfrUIDj5Z0Us6mglHjfiErNFNnLhtak2SvbiowlE8azLvqWWkn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=eKsLf1hULA+YZtusPifYGyUqaa8TyLF8E6HHB9TaBi4Oc2aPM4blj9foZjzmioDPKaNiGAueuu/+CAIjN+Tsbi0F6bN+qwcEAVG2m70xF7dmeG0/I3yKU2d4xG6eMV2udw17TfV5iWBWAtHkQLmFfrS7CfpJjYcaxfTEuK1bYfc= Received: by 10.65.222.11 with SMTP id z11mr10805834qbq.1175180425065; Thu, 29 Mar 2007 08:00:25 -0700 (PDT) Received: by 10.65.150.17 with HTTP; Thu, 29 Mar 2007 08:00:24 -0700 (PDT) Message-ID: Date: Thu, 29 Mar 2007 11:00:24 -0400 From: "Peter Keegan" To: java-user@lucene.apache.org Subject: Re: FieldSortedHitQueue enhancement In-Reply-To: <20070329144800.4892.qmail@web50312.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43185_26635173.1175180424962" References: <20070329144800.4892.qmail@web50312.mail.re2.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_43185_26635173.1175180424962 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The duplicate check would just be on the doc ID. I'm using TreeSet to detect duplicates with no noticeable affect on performance. The PQ only has to be checked for a previous value IFF the element about to be inserted is actually inserted and not dropped because it's less than the least value already in there. So, the TreeSet is never bigger than the size of the PQ (typically 25 to a few hundred items), not the size of all hits. Peter On 3/29/07, Otis Gospodnetic wrote: > > Hm, removing duplicates (as determined by a value of a specified document > field) from the results would be nice. > How would your addition affect performance, considering it has to check > the PQ for a previous value for every candidate hit? > > Otis > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > Simpy -- http://www.simpy.com/ - Tag - Search - Share > > ----- Original Message ---- > From: Peter Keegan > To: java-user@lucene.apache.org > Sent: Thursday, March 29, 2007 9:39:13 AM > Subject: FieldSortedHitQueue enhancement > > This is request for an enhancement to FieldSortedHitQueue/PriorityQueue > that > would prevent duplicate documents from being inserted, or alternatively, > allow the application to prevent this (reason explained below). I can do > this today by making the 'lessThan' method public and checking the queue > before inserting like this: > > if (hq.size() < maxSize) { > // doc will be inserted into queue - check for duplicate before > inserting > } else if (hq.size() > 0 && !hq.lessThan((ScoreDoc)fieldDoc, > (ScoreDoc)hq.top()) { > // doc will be inserted into queue - check for duplicate before > inserting > } else { > // doc will not be inserted - no check needed > } > > However, this is just replicating existing code in > PriorityQueue->insert(). > An alternative would be to have a method like: > > public boolean wouldBeInserted(ScoreDoc doc) > // returns true if doc would be inserted, without inserting > > The reason for this is that I have some queries that get expanded into > multiple searches and the resulting hits are OR'd together. The queries > contain 'terms' that are not seen by Lucene but are handled by a > HitCollector that uses external data for each document to evaluate hits. > The > results from the priority queue should contain no duplicate documents > (first > or last doc wins). > > Do any of these suggestions seem reasonable?. So far, I've been able to > use > Lucene without any modifications, and hope to continue this way. > > Peter > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-user-help@lucene.apache.org > > ------=_Part_43185_26635173.1175180424962--