ok when my head is cooled down, I remember this old school issue... that I
have been dealing with it myself.
so I do not expect this can be straighten out or fixed in anyways.
basically when you have to sorted results sets you need to merge, and
paginate through, it is never an easy job (if all i
any update on this?
will this be addressed/fixed?
in our system, our UI will allow user to paginate through search results.
As my in deep test find out, if the rows=0, the results size is consistently
the total sum of the documents on all shards regardless there is any
duplicates; if the rows
I can cross check our shards once again, but I am sure this is not the case.
Regards,
Rohit
Mobile: +91-9901768202
-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
Sent: 08 August 2012 21:04
To: solr-user@lucene.apache.org
Subject: Re: numFound changes on
Our documents are keyed with UUIDs, and we shard chronologically. The
write events are issued as part of a SQS queue that only allows one
reader to see the message. I think it's pretty unlikely that we have
more than one document with the same uniquekey.
I can actually prove this if it will help t
: We are using Solr3.6 and 2 shards, we are noticing that when we fire a query
: with start as 0 and rows X the total numFound and the total numFound changes
: when we fire the same exact query with start as y and rows X.
The only situation where i've ever heard of this happening is when
multipl
Sorry, in my time range example, I forgot to mention that you can
repeatedly execute the 8 hour query and receive no results, even after
the 7 hour query retrieves them.
Kind of an important detail to not forget. :)
Michael Della Bitta
Appinions |
We've noticed some pretty non-deterministic behavior with sharded
setups as well.
One thing we've noticed is that a query server can hang on to the set
of document ids that correspond to a given query even if caching is
off, which results in some weird behavior, such as a query like:
timestamp:[N
