Thanks everyone! I checked the system metrics during the optimization
process. CPU usage is quite low, there is no I/O wait, and memory usage is
not much different from before the docValues change. So I wonder what
could be the bottleneck.
Thanks,
Wei
On Sat, Nov 3, 2018 at 1:38 PM Erick
Hi everyone,
My company currently uses SOLR to completely hydrate client objects by
storing all fields (stored=true). Therefore we have 2 types of fields:
1. indexed=true | stored=true : For fields that will be used for
searching, sorting, etc.
2. indexed=false | stored=true: For fields
Going from my phone so it'll be terse. See uninvertingmergeuodateprocessor
(or something like that). Also, there's an idea in SOLR-12259 IIRC, but
that'll be in 7.6 at the earliest.
On Sat, Nov 3, 2018, 07:13 Shawn Heisey On 11/3/2018 5:32 AM, Dave wrote:
> > On a side note, does adding
On 11/3/2018 5:32 AM, Dave wrote:
On a side note, does adding docvalues to an already indexed field, and then
optimizing, prevent the need to reindex to take advantage of docvalues? I was
under the impression you had to reindex the content.
You must reindex when changing the schema to add
On a side note, does adding docvalues to an already indexed field, and then
optimizing, prevent the need to reindex to take advantage of docvalues? I was
under the impression you had to reindex the content.
> On Nov 3, 2018, at 4:41 AM, Deepak Goel wrote:
>
> I would start by monitoring the
I would start by monitoring the hardware (CPU, Memory, Disk) & software
(heap, threads) utilization's and seeing where the bottlenecks are. Or what
is getting utilized the most. And then tune that parameter.
I would also look at profiling the software.
Deepak
"The greatness of a nation can be
