SOLR query times

around 100 msec, subsequent queries would take around 15 msec. Is there some sort of caching happening at Lucene level? Thanks for your help, Sammy Yu

Re: SOLR query times

some pieces of the index into memory and you may see the > FieldCache in action, depending on sorting, not to mention you are also > seeing operating system caching take place. > > Is there some reason you don't want these or are you just trying to > understand the why? > >

Standard request with functional query

Hi guys, I have a standard query that searches across multiple text fields such as q=title:iphone OR bodytext:iphone OR title:firmware OR bodytext:firmware This comes back with documents that have iphone and firmware (I know I can use dismax handler but it seems to be really slow), which is gr

Slow Response time after optimize

Hi guys, I have a typical master/slave setup running with Solr 1.3.0. I did some basic scalability test with JMeter and tweaked our environment and determined that we can handle approximately 26 simultaneous threads and get end-to-end response times of under 200ms even with typically every 5 mi

Re: Standard request with functional query

st sorting by dateCreated rather than having dateCreated being a part of the score. Thanks, Sammy n Thu, Dec 4, 2008 at 1:35 PM, Sammy Yu wrote: > Hi guys, >I have a standard query that searches across multiple text fields such as > q=title:iphone OR bodytext:iphone O

SOLR 1.4 and 1.3 diff and other

Hi, I'm making a simple query that uses the standard query handler to make constructed query such as title:iphone OR text:firmware. Next, I am use the filterquery to limit the amount of items to data from within the last year via fq=+dateCreated:[NOW-1YEAR/MONTH TO NOW/MONTH] which is significa

Re: SOLR 1.4 and 1.3 diff and other

people. Thanks, Sammy On Wed, Dec 17, 2008 at 5:36 PM, Yonik Seeley wrote: > On Wed, Dec 17, 2008 at 7:52 PM, Sammy Yu wrote: >> I read somewhere that there are contention issues with the current >> cache implementation of LRUCache in 1.3 in that it is synchronous, >> cou

debugQuery missing boost

Hi, I'm trying to get some information how boost is used in the ranking calculation via the debugQuery parameter for the following query: (bodytext:iphone OR bodytext:firmware)^2.0 OR dateCreatedYear:2009^5.0 For one of the matching documents I can see: 4.7144237 = (MATCH) sum of: 2.2903786

Query Performance of -field:[* TO *]

field. Only if it's another color will I will populate the field. My question is if I try to make a query such as -color:[* TO *] will it be much slower than -color:green? Thanks for your help in advance. Best, Sammy Yu