All non-cached filters will be executed together (leapfrog between them)
and will be sorted by the filter cost (I guess that, since you aren't
setting a cost, then the order of the input matters). You can try setting
a cost in your filters (lower than 100, so that they don't become post
filters)
Sorting and faceting takes a lot of memory. From your charts, I would try
a 31 GB heap. That would make GC faster. 680 ms is very long for a GC
and can cause problems.
Combine a 680 ms GC with a 100 ms soft commit time and you can have
lots of trouble.
Change your soft commit time to 1 (ten s
Thanks for the suggestion, Alex. It doesn't appear that
IndexOrDocValuesQuery (at least in Solr 7.7.1) supports the PostFilter
interface. I've tried various values for cost on each of the fq and it
doesn't change the QTime.
So, after digging around a bit even though
{!cache=false}taggedTickets_tic
Thanks for quick reply.
I assume caches (are they too large?), perhaps uninverted indexes.
Docvalues would help with latter ones. Do you use them?
>> We do not use any cache. we disabled the cache from solrconfig.xml
here is my solrconfig .xml and schema.xml
https://drive.google.com/file/d/12SHl3Y
I am new to this SOLR-ZOOKEEPER. I am not able to understand the
compatibility thing. For example, I am using SOLR 7.5.0 which uses ZK
3.4.11. So SOLR 7.5.0 will not work with ZK 3.4.10?
Can someone please confirm this?
Thanks,
Mithun Seal
--
Sent from: https://lucene.472066.n3.nabble.com/Solr
vishal patel kirjoitti 10.7.2020 klo 12.45:
> Thanks for your input.
>
> Walter already said that setting soft commit max time to 100 ms is a recipe
> for disaster
>>> I know that but our application is already developed and run on live
>>> environment since last 5 years. Actually, we want to sh
Thanks for your input.
Walter already said that setting soft commit max time to 100 ms is a recipe for
disaster
>> I know that but our application is already developed and run on live
>> environment since last 5 years. Actually, we want to show a data very
>> quickly after the insert.
you have
thanks for share. nice article.
Charlie Hull wrote:
Thought you might enjoy Eric's blog, it's taken him a while! Some good
hints here for those of you interested in contributing more to Solr.
https://opensourceconnections.com/blog/2020/07/10/i-became-a-solr-committer-in-4662-days-heres-how-yo
Thanks, interesting reading
On Fri, Jul 10, 2020 at 11:18 AM Charlie Hull wrote:
> Hi all,
>
> Thought you might enjoy Eric's blog, it's taken him a while! Some good
> hints here for those of you interested in contributing more to Solr.
>
>
> https://opensourceconnections.com/blog/2020/07/10/i-b
Hi:
Hope PayloadCheckQParserPlugin can support operator parameters, support
the operator is a phrase or or multiple values.
As PayloadScoreQParserPlugin
1. Analyze parameters. localParams.get("operator", DEFAULT_OPERATOR);
2. Create SpanQuery, call PayloadUtil
Hi all,
Thought you might enjoy Eric's blog, it's taken him a while! Some good
hints here for those of you interested in contributing more to Solr.
https://opensourceconnections.com/blog/2020/07/10/i-became-a-solr-committer-in-4662-days-heres-how-you-can-do-it-faster/
Cheers
Charlie
--
Char
Walter already said that setting soft commit max time to 100 ms is a
recipe for disaster. That alone can be the issue, but if you're not
willing to try higher values, there's no way of being sure. And you have
huge JVM heaps without an explanation for the reason. If those do not
cause problems, you
12 matches
Mail list logo
