Hello, Shawn, Toke Eskildsen and Solr Community: > Since version 7.5, optimize with TieredMergePolicy (the default policy) > respects the maximum segment size, which defaults to 5GB. Thank you for your reply. Indeed, there was approximately a total of 9GB index size. So, as you tell me, TieredMergePolicy respected to the maximum size.
> Your PDF attachment did not make it to the list. We cannot see it. The > mailing list rarely lets attachments through. Thank you for your response. I am sorry for sending an attachment, which mailing list does not send to. I did not know about that. For the next opportunity to share table-formatted data, what is the best way to share data with all of you? Should I share a Google spreadsheet URL? How people usually do? > The one place where there is a real difference is with String faceting > as >= 2 segments means that String ordinals must be coordinated between > segments Let me confirm what you say (since I am not a native speaker of English and I am new to Solr) When we request a facet query (like below) to 2 Solrs: one with multiple segments and the other is only one segment, we will have different performance result? "http://localhost:8983/solr/collection1/ select?q=*:*& fl=id,cat,manu,price& indent=true& rows=2& facet=true& facet.field=price& facet.sort=index& facet.limit=10" Can we configure up-front faceting or one-the-fly facet method? I would like to see the difference to understand Solr's behavior if it is possible. Sincerely, Kaya Ota 2019年5月20日(月) 18:38 Toke Eskildsen <t...@kb.dk>: > On Sun, 2019-05-19 at 13:36 -0600, Shawn Heisey wrote: > > I would not expect to see a really noticeable performance increase > > by going from two segments to one. > > The one place where there is a real difference is with String faceting > as >= 2 segments means that String ordinals must be coordinated between > segments. Depending on faceting method this is done up-front (with an > obvious fist-call time penalty, some memory overhead to hold the > mapping and a slight running overhead for consulting the map) or on- > the-fly (with non-surprising running overhead). > > It becomes relevant with large indexes and/or setups where performance > is very important. > > - Toke Eskildsen, Royal Danish library > > >
