re will change.*
> > first time it work fine but if I am changing la alone and firing the
> query
> > again the result remains in the same order as first query result.Which
> > means sorting is not happening even the score is different.But If I am
> > changing the cit=Chennai
ging la alone and firing the query
> again the result remains in the same order as first query result.Which
> means sorting is not happening even the score is different.But If I am
> changing the cit=Chennai to cit=someCity then I am getting result in
> proper order,means sorting works
ennai to cit=someCity then I am getting result in
proper order,means sorting works fine.
At any rate, queryResultCache is unlikely to impact
much. All it is is
*a map containing the query and the first few document IDs *(internal
Lucene).
which means query is the unique key and list of document
This seems like an XY problem, you're asking for
specifics on doing something without any indication
_why_ you think this would help. Nor are you explaining
what the problem you're having is in the first place.
At any rate, queryResultCache is unlikely to impact
much. All it i
is there any way programmatically disable/enable solr queryResultCache?
I am using SolrJ.
Thanks & Regards,
Senthilnathan V
t; problem here is sorting.
> >
> > I am sorting the results using bscore and relscore likebelow,
> >
> > *$bscore desc,$relscore desc*
> >
> > first time it works fine.
> >
> > above bscore and relscore will change based on lux_amenities but
> >
ore desc*
>
> first time it works fine.
>
> above bscore and relscore will change based on lux_amenities but
> lux_amenities is neither part of fq nor q.So if second time we are
> changing the lux_amenities alone and firing the query means it is giving
> the result in same order as fi
above bscore and relscore will change based on lux_amenities but
lux_amenities is neither part of fq nor q.So if second time we are
changing the lux_amenities alone and firing the query means it is giving
the result in same order as first query even the bscore and relscore are
different.
So I disabled t
No, the queryResultCache contains the top N for the query, _including_
the filters.
The idea is that you should be able to get the next page of results
without going
to any searching code. You couldn't do this if in the scenario you describe.
If your filters are truly unique, you'll gai
I am filtering by geospatial search,
people find items nearest to them). Also some additional user specific
filters. So filter queries will always be unique, but the people may use
common keywords to lookup, so main query (q param) may be common most
times. So if queryResultCache contain all the results retu
First, why is it important to you? General background or a specific
problem you're trying to address?
But to answer, no. The queryResultCache contains the top N
ids for the query. You control N by setting
in solrconfig.xml. It's often set to 2x the usual "rows" paramete
Does the queryResultCache, contain all the results returned by main query(q
param) or it contains results prepared after all filter queries ?
On Wed, Jul 31, 2013 at 3:49 PM, Chris Hostetter
wrote:
> there is however a "group.cache.percent" option tha you might look into --
> but i honestly have no idea if that toggles the use of queryResultCache or
> something else, i havn't played with it before...
That'
: it's quite long but this request uses both faceting and grouping. If I
: remove the grouping then the cache is used. Is this a normal behavior or
: a bug?
I believe that is expected -- i don't think grouping can take advantage of
the queryResultCache because of how it collects
Also we do not have any useFilterForSortedQuery in our config. So we are
relying on the default which I guess is false.
From: Jean-Sebastien Vachon
Sent: Wednesday, July 31, 2013 3:44 PM
To: solr-user@lucene.apache.org
Subject: RE: queryResultCache
__
From: Jean-Sebastien Vachon
Sent: Wednesday, July 31, 2013 2:38 PM
To: solr-user@lucene.apache.org
Subject: RE: queryResultCache showing all zeros
Looks like the problem might not be related to Solr but to a proprietary system
we have on top of it.
I made some queries with fa
thing
From: Chris Hostetter
Sent: Wednesday, July 31, 2013 1:58 PM
To: solr-user@lucene.apache.org
Subject: Re: queryResultCache showing all zeros
: We just configured a new Solr cloud (5 nodes) running Solr 4.3, ran
: about 200 000 queries taken fro
: and when I look at each node of the cloud, all of them are showing no
: activity (see below) regarding the queryResultCache... all other caches
: are showing some activity. Any idea what could cause this?
Can you show us some examples of hte types of queries you are executing?
Do you have
when I look at each node of
the cloud, all of them are showing no activity (see below) regarding the
queryResultCache... all other caches are showing some activity. Any idea what
could cause this?
*
org.apache.solr.search.LRUCache
*
version:
1.0
*
description:
LRU Cache(maxSize=512
: By the way, if the issure is ok , how can I post my code?
Take a look at this wiki page for imformation on submitting patches...
https://wiki.apache.org/solr/HowToContribute
https://wiki.apache.org/solr/HowToContribute#Generating_a_patch
...you can attach your patch directly to hte Jira issu
Hello,
QueryResultCache should not related with the order of fq's list.
There are two case query with the same meaning below. But the case2 can't
use the queryResultCache when case1 is executed.
case1: q=:&fq=field1:value1&fq=field2:value2
case2: q=:&fq=f
as fast as we can.
Thanks!
Robi
-Original Message-
From: Shawn Heisey [mailto:s...@elyograg.org]
Sent: Tuesday, January 29, 2013 2:24 PM
To: solr-user@lucene.apache.org
Subject: Re: queryResultCache *very* low hit ratio
On 1/29/2013 1:36 PM, Petersen, Robert wrote:
> My queryResultC
m] On Behalf Of Yonik Seeley
Sent: Tuesday, January 29, 2013 2:46 PM
To: solr-user@lucene.apache.org
Subject: Re: queryResultCache *very* low hit ratio
One other thing that some auto-warming of the query result cache can achieve is
loading FieldCache entries for sorting / function queries so re
tries for these fields.
-Yonik
http://lucidworks.com
On Tue, Jan 29, 2013 at 3:36 PM, Petersen, Robert wrote:
> Hi solr users,
>
> My queryResultCache hitratio has been trending down lately and is now at
> 0.01%, and also it's warmup time was almost a minute. I have lowered
On 1/29/2013 1:36 PM, Petersen, Robert wrote:
My queryResultCache hitratio has been trending down lately and is now at 0.01%,
and also it's warmup time was almost a minute. I have lowered the autowarm
count dramatically since there are no hits anyway. I also wanted to lower my
aut
Hi solr users,
My queryResultCache hitratio has been trending down lately and is now at 0.01%,
and also it's warmup time was almost a minute. I have lowered the autowarm
count dramatically since there are no hits anyway. I also wanted to lower my
autowarm counts across the board because
: When I run dismax queries I see there are no lookups in the
: queryResultCache. If I remove the field collapsing - lookups happen. I
: can't find any mention of this anywhere or think of reason why this should
I'm not very familiar with the grouping code, but i think the
crux o
true
When I run dismax queries I see there are no lookups in the
queryResultCache. If I remove the field collapsing - lookups happen. I
can't find any me
Thanks Chris,
Now it all makes sense. One of my filters is a date range filter with the
current time as a lower range, so it changes with every query. I have just
tried to comment it out and I see the queryResultCache being utilized. I
will try to round the currentTimeMillis down to the nearest
: In the /admin/stats.jsp I have noticed that if the code above gets executed
: then my queryResultCache hit count does not increase.
Filters are part of the cache key for the queryResultCache (because the
cache contains the sorted paginated results *after* filters have been
applied) so if
Solr version: 3.2.0
--
View this message in context:
http://lucene.472066.n3.nabble.com/queryResultCache-hit-count-is-not-being-increased-when-programmatically-adding-Lucene-queries-as-filt-tp3586892p3586904.html
Sent from the Solr - User mailing list archive at Nabble.com.
) {
filters = new ArrayList();
rb.setFilters(filters);
}
filters.add(userAccessQuery);
filters.add(auctionEndConditionQuery);
}
In the /admin/stats.jsp I have noticed that if the code above gets executed
then my queryResultCache hit count does not increase
d the
result cache.
--
View this message in context:
http://lucene.472066.n3.nabble.com/QueryResultCache-question-tp3130135p3130603.html
Sent from the Solr - User mailing list archive at Nabble.com.
th the index until a commit
is issued.
On Fri, Jul 1, 2011 at 2:47 PM, arian487 wrote:
> So it seems the things in the queryResultCache have no TTL, I'm just
> curious
> how it works if I reindex something with new info? I am going to be
> reindexing things often (I'd sort by
So it seems the things in the queryResultCache have no TTL, I'm just curious
how it works if I reindex something with new info? I am going to be
reindexing things often (I'd sort by last login and this changes fast).
I've been stepping through the code and of course if the same
forget to say: thanks again! Now the cache gets hits!
Regards,
Peter.
> On Wed, Aug 18, 2010 at 4:34 PM, Peter Karich wrote:
>
>> Thanks a lot Yonik! Rounding makes sense.
>> Is there a date math for the 'LAST_COMMIT'?
>>
> No - but it's an interesting idea!
>
> -Yonik
> http://www.lucid
Hi Yonik,
would you point me to the Java classes where solr handles a commit or an
optimize and then the date math definitions?
Regards,
Peter.
> On Wed, Aug 18, 2010 at 4:34 PM, Peter Karich wrote:
>
>> Thanks a lot Yonik! Rounding makes sense.
>> Is there a date math for the 'LAST_COMMIT'?
On Wed, Aug 18, 2010 at 4:34 PM, Peter Karich wrote:
> Thanks a lot Yonik! Rounding makes sense.
> Is there a date math for the 'LAST_COMMIT'?
No - but it's an interesting idea!
-Yonik
http://www.lucidimagination.com
Thanks a lot Yonik! Rounding makes sense.
Is there a date math for the 'LAST_COMMIT'?
Peter.
> On Tue, Aug 17, 2010 at 6:29 PM, Peter Karich wrote:
>
>> my queryResultCache has no hits. But if I am removing one line from the
>> bf section in my dismax handler a
On Tue, Aug 17, 2010 at 6:29 PM, Peter Karich wrote:
> my queryResultCache has no hits. But if I am removing one line from the
> bf section in my dismax handler all is fine. Here is the line:
> recip(ms(NOW,date),3.16e-11,1,1)
NOW has millisecond resolution, so it's actually a d
Hi all,
my queryResultCache has no hits. But if I am removing one line from the
bf section in my dismax handler all is fine. Here is the line:
recip(ms(NOW,date),3.16e-11,1,1)
According to
http://wiki.apache.org/solr/SolrRelevancyFAQ#How_can_I_boost_the_score_of_newer_documents
this should be
ot;Phillip Farber" wrote:
I'm trying to understand the purpose of the initialSize parameter for
the queryResultCache and documentCache. Is it correct that it controls
how much heap is allocated to each cache at startup?
I can see how it makes sense for queryResultCache since it is docum
I'm trying to understand the purpose of the initialSize parameter for
the queryResultCache and documentCache. Is it correct that it controls
how much heap is allocated to each cache at startup?
I can see how it makes sense for queryResultCache since it is documented
as an "ordere
Shalin Shekhar Mangar schrieb:
On Tue, Jun 9, 2009 at 7:47 PM, Michael Ludwig
wrote:
Given the following three filtering scenarios of (a) x:bla, (b)
y:blub, and (c) x:bla AND y:blub, will I end up with two or three
distinct filters? In other words, may filters be composites or are
they decomp
filter query results?
Maximum number of filters that can be cached.
> * queryResultCache/@size - query results?
Maximum number of queries (DocLists) that can be cached.
> * documentCache/@size - documents?
Correct.
> So if I know my tiny documents don't take up much memo
Common cache configuration parameters include @size ("size" attribute).
http://wiki.apache.org/solr/SolrCaching
For each of the following, does this mean the maximum size of:
* filterCache/@size - filter query results?
* queryResultCache/@size - query results?
* documentCache/@size -
Got it. Smart.
Thx
On 1/6/08, Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
> : number than the default one and i was wondering is there any disadvantage
> in
> : having a big number/ cache?BTW, where is the TTL controlled ?
>
> no disadvantage as long as you've got the RAM ... NOTE: the magic "512
: number than the default one and i was wondering is there any disadvantage in
: having a big number/ cache?BTW, where is the TTL controlled ?
no disadvantage as long as you've got the RAM ... NOTE: the magic "512"
number you refered to isn't a "default" -- it's an "example" in the "example"
so
n 6, 2008 12:59 AM, s d <[EMAIL PROTECTED]> wrote:
> > What is the best approach to tune queryResultCache ?For example the
> default
> > size is: size="512" but since a document id is just an int (it is an
> int,
> > right?) ,i.e 4 bytes why not set size
On Jan 6, 2008 12:59 AM, s d <[EMAIL PROTECTED]> wrote:
> What is the best approach to tune queryResultCache ?For example the default
> size is: size="512" but since a document id is just an int (it is an int,
> right?) ,i.e 4 bytes why not set size to 10,000,000 for e
What is the best approach to tune queryResultCache ?For example the default
size is: size="512" but since a document id is just an int (it is an int,
right?) ,i.e 4 bytes why not set size to 10,000,000 for example (it's only
~38Mb).
I sense there is something that I'm missi
I just looked into it more... for the case I'm looking at, getSize()
does not help because it returns how many elements are in the cache,
not the max size.
I can get what I need with:
SolrConfig.config.getInt( "query/filterCache/@size", -1 );
so lets put off adding getters to SolrIndexSearcher
On 4/4/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Apr 4, 2007, at 7:28 PM, Ryan McKinley wrote:
> Is there / should there be a way to access the three core caches?
there should. +1
> I want to be able to programmatic check the cache sizes and make sure
> they are big enough for facetin
On Apr 4, 2007, at 7:28 PM, Ryan McKinley wrote:
Is there / should there be a way to access the three core caches?
there should. +1
I want to be able to programmatic check the cache sizes and make sure
they are big enough for faceting.
i could use the same thing!
Erik
Is there / should there be a way to access the three core caches?
You can access user defined caches from:
searcher.getCache( "name" );
The three core caches only have private access from SolrIndexSearcher.
I want to be able to programmatic check the cache sizes and make sure
they are big enou
55 matches
Mail list logo