Hi Erick,
thanks for the reply.
Just to follow up, I'm using "unified" highlighter (fastVector does not
work for my purposes). I search and highlight on a multivalued string
string field which contains small strings (usually less than 200 chars).
This multivalued field is subject to various process
I suspect this is spurious. Norms are just an encoding
of the length of a field, offhand I have no clue how having
them (or not) would affect highlighting at all.
Term _vectors_ OTOH could have a major impact. If
FastVectorHighlighter is not used, the highlighter has
to re-analyze the text in ord
Thanks Shawn, Alessandro for your feedback.
sorry if I took this for granted, I was just trying to understand if there
could be a performance gain when *real* queries happens (against other
fields too).
So a smaller collection, a smaller document space, a smaller query in terms
of number of filter
Seconding Shawn, if your queries will always aim the active documents you
will see :
High level this is what is going to happen :
A) You need to run your query + a filter query that will retrieve only
active documents.
The filter query results will be cached.
Solr will query over the entire docume
On 11/4/2016 8:22 AM, Vincenzo D'Amore wrote:
> Given 2 collection A and B:
>
> - A collection have 5 M documents with an attribute active: true/false.
> - B collection have only 2.5 M documents, but all the documents have
> attribute active:true
> - in any case, A or B, I can only search upon docu
Thank you, everything seems clear.
07.05.2013 20:17 пользователь "Andre Bois-Crettez"
написал:
> Some clarifications :
>
> 1) *lots of docs, few queries* : If you have a high number of documents
> (+dozen millions) and lowish number of queries per second (say less than
> 10), replicas will not h
Some clarifications :
1) *lots of docs, few queries* : If you have a high number of documents
(+dozen millions) and lowish number of queries per second (say less than
10), replicas will not help to reduce the Qtime. For this kind of task
it is better to shard the index, as each query will effecti
P.S. Sorry for misspelling your name, Jan
2013/5/7 Stanislav Sandalnikov
> Hi Yan,
>
> Thanks for the quick reply.
>
> Thus, replication seems to be the preferable solution. QTime decreases
> proportional to replications number or there are any other drawbacks?
>
> Just to clarify, what amount
Hi Yan,
Thanks for the quick reply.
Thus, replication seems to be the preferable solution. QTime decreases
proportional to replications number or there are any other drawbacks?
Just to clarify, what amount of documents stands for "tons of documents" in
your opinion? :)
2013/5/7 Jan Høydahl
>
Hi,
It depends(TM) on what kind of search performance problems you are seeing.
If you simply have so high query load that the server starts to kneal, it will
definitely not help to shard, since ALL the shards will still be hit with
ALL the queries, and you add some extra overhead with sharding as
And yet, if you are experiencing performance problems, consider
optimizing regularly. If not, why worry?
-Mike
On 19-Feb-08, at 4:17 PM, Otis Gospodnetic wrote:
Hi,
If your mergeFactor is "reasonable" (e.g. default 10), Lucene will
keep the number of segments in the index under control.
Hi,
If your mergeFactor is "reasonable" (e.g. default 10), Lucene will keep the
number of segments in the index under control. Your index will not be
optimized at all times, but the number of segments will not be astronomical and
not having a single-segment (i.e. optimized) index will not caus
12 matches
Mail list logo
