Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of grant.ingersoll@gmail.com
 designates 64.233.184.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=rGaVRbtBI+J9InktCmiCxFyWKP5FYjRQjqM8X3gjImWX72mi+pum0xdgaFaxcvd1VMaO/V6jz2enSV7/slswilxgRnCjiC/X+hBcJh7FppsYyFn/ZE1g3Qy7Q6yg8y5KmtppihgIOctwAun86tAQb8dFUW3TwI7ePQBisEdCWQE=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <e994873a0708150746i5689ae60ud09a0e4f76638d14@mail.gmail.com>
References: <86111134-3930-4393-B49B-32557A19F151@apache.org>
 <e994873a0707230551g351fd1d3n4dfc0d59a7b5e056@mail.gmail.com>
 <829C71B5-BA1A-413F-BB28-E382BBF8A30D@gmail.com>
 <e994873a0707241502i6bc98a23s695990db9a0b52e2@mail.gmail.com>
 <8636616C-8567-499E-BC71-6BE07E868129@apache.org>
 <e994873a0708091329v6d93344co332e0b8d777bd423@mail.gmail.com>
 <e994873a0708100803y7b3a45c9u828486478d9ca9ef@mail.gmail.com>
 <665A433D-F21F-4F74-B495-7008DFE1B432@apache.org>
 <e994873a0708101527q75a7f263p85200e97d042c31@mail.gmail.com>
 <E34BB882-1D30-4DD1-9B8B-218830098449@gmail.com>
 <e994873a0708150746i5689ae60ud09a0e4f76638d14@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E80DEE9A-5AB3-48CB-A99F-927F908BD8C8@gmail.com>
Content-Transfer-Encoding: 7bit
From: Grant Ingersoll <grant.ingersoll@gmail.com>
Subject: Re: Best Practices for getting Strings from a position range
Date: Wed, 15 Aug 2007 11:10:06 -0400
To: java-dev@lucene.apache.org


On Aug 15, 2007, at 10:46 AM, Peter Keegan wrote:

> Grant,
>
> I built an index as described here:
> http://www.nabble.com/SpanQuery-and-database-join-tf4262902.html
>
> Many documents have only 1 or 2 rows, some have dozens.
> Here is a typical query without spans:
>
> +((+contents:quaker +contents:cereal) (+boost50:quaker  
> +boost50:cereal))
> +literals:co$us), sort=<custom:"feedbabe":
> RoundingScoreDocComparator@8c169d05>,"dateactiveR"!
>
>
> Here is a typical query with spans:
>
> +spanNear([adliterals:jb$1, adliterals:co$us], 8, false)
> +(+((+contents:quaker +contents:cereal) (+boost50:quaker  
> +boost50:cereal))
> +literals:co$us), sort=<custom:"feedbabe":
> RoundingScoreDocComparator@8c169d05>,"dateactiveR"!
>
> The addition of the spanNear clause caused the 10X decrease in  
> throughput. I
> could probably change the way rows are indexed and use ordered  
> terms, which
> seems to be a bit faster (only 5X decrease)

In looking at the code, it makes sense that an ordered SpanNearQuery  
would be faster.

I am still trying to dig into the logistics of the Unordered  
SpanNearQuery, as it is the only thing hanging me up on adding  
payload access to Spans.  I need to step through and debug.  As your  
stack trace showed, there is a lot of work taking place to manage the  
priority queue that is created.  I just don't understand the relation  
between the SpanCells, the "ordered" List and the PriorityQueue  
"queue" just yet.  It seems the SpanCells make a linked list, the  
"ordered" list is for getting the spans from the sub queries and the  
queue seems to rearrange the ordered list

If anyone wants to chip in with pseudocode explaining what is going  
on in NearSpansUnordered.java it would be helpful. 
  

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org