The number of deleted documents will bounce around. The default TieredMergePolicy has a rather complex algorithm that decides which segments to merge, and the percentage of deleted docs in any given segment is a factor, but not the sole determinant.
Merging is not really based on the raw number of segments, rather on the number of segments of similar size. But the short answer is “no, you don’t have to configure anything explicitly”. The percentage of deleted docs should max out at around 30% or so, although that’s a soft number, it’s usually lower. Unless you have some provable performance problem, I wouldn’t worry about it. And don’t infer anything until you’ve indexed a _lot_ of docs. Oh, and I kind of dislike numDocs as the trigger and tend to use time on the theory that it’s easier to explain, whereas when commits happen when using maxDocs varies depending on the throughput rate. Best, Erick > On Apr 15, 2020, at 1:28 PM, Kayak28 <kaya.ota....@gmail.com> wrote: > > Hello, Solr Community: > > I would like to ask about Default's Merge Policy for Solr 8.3.0. > My client (SolrJ) makes a commit every 10'000 doc. > I have not explicitly configured Merge Policy via solrconfig.xml > For each indexing time, some documents are updated or deleted. > I think the Default Merge Policy will merge segments automatically > if there are too many segments. > But, the number of deleted documents is increasing. > > Is there a Default Merge Policy Configuration? > Or, do I have to configure it? > > Sincerely, > Kaya Ota > > > > -- > > Sincerely, > Kaya > github: https://github.com/28kayak
