hi community,
I understand that optimize builds a NEW index from the live one, and then
swaping them.
And that it is best to schedule optimize with care.
Can we still update and query the live index while optimize is on the go?
Or is the live index being locked during optimize?
10X
shlomiJ
hola,
1) When distributing search across several Shards, is the merged result
reflects the overall ranking, cross-shards?
I'm talking about stuff like "document frequency".
I guess it does, otherwise distributed search wouldn't have overhead.
talking about overhead,
2) is there a known ratio of t
Hi,
I use Solr 1.4 version and I have a question about SOLR sort order.
Requirement : Sort names(e.g. : location names like Dallas(City), las
vegas(City), Texas(State), India(Country), Canada(Country), etc..) based on
category(e.g. : CITY, STATE, COUNTRY, etc..)
How to sort the SOLR results bas
Thanks Gora for clarifying. So if my understanding is correct then the total
response time is not logged in solr logs and I need to rely on the QTime in
the response.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Interpreting-solr-response-time-from-log-tp3624340p3624931.htm
In addition to Ahmet's comment, the other rule of thumb is that
fqs do NOT influence a document's score, it's strictly an
include/exclude decision.
The new cache=false capabilities allow you to keep one-off
fqs from using entries in your cache BTW...
Best
Erick
On Fri, Dec 30, 2011 at 3:45 AM, r
On Sun, Jan 1, 2012 at 8:58 PM, Jithin wrote:
> Thanks Gora for clarifying. So if my understanding is correct then the total
> response time is not logged in solr logs and I need to rely on the QTime in
> the response.
If your log level is set at least to INFO, as it should be by default Solr doe
Chantal:
bq: The problem with the wildcard searches is that the input is not
analyzed.
As of 3.6/4.0, this is no longer entirely true. Some analysis is
performed for wildcard searches by default and you can
specify most anything you want if you really need to see:
https://issues.apache.org/jira/b
This may be the impetus for Hoss creating SOLR-2996.
I suspect this will go away if you use the correct
match-all-docs syntax, i.e. q=*:* rather than q=*
Hoss' suggestion in 2996 is to "do the right thing" with
q=*, but for now you need to use the right syntax.
But I'm not sure what highlighting
There's no index locking while optimizing that I know of.
But optimize is not all that necessary usually unless
you have a pretty static index, in fact under the
covers it's been renamed to forceMerge or something
just to keep it from sounding so necessary. The
resource reclamation & etc. happens a
1> Yes. Note that the distributed tf/idf is an issue, although it's changing.
That is, if your documents are statistically very different across
shards, the scores aren't really comparable. This is changing, but
I don't think it's committed yet.
2> Well, you're mixing apples and orang
There's no good way of enforcing this as far as I know
as you've outlined the problem. You can easily specify
multiple sort criteria, where ties in the first criteria
are broken by the second criteria and so on.
So, if your records have *no* city value you can do what
you want by specifying the ci
We fullfilled a similar requirement by creating a new field that is
populated at client-level (a standalone app that converts binary data
in solr input documents)
Andrea
On 1/1/12, Erick Erickson wrote:
> There's no good way of enforcing this as far as I know
> as you've outlined the problem. Yo
On 01/01/2012 07:48 AM, Erick Erickson wrote:
This may be the impetus for Hoss creating SOLR-2996.
Yep, it is indeed, though I believe this problem can also happen when a
user searches for something like q=a* in a big index. I need a bigger
index to know for sure about that, but from what I've
13 matches
Mail list logo
