[
https://issues.apache.org/jira/browse/SOLR-17192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844785#comment-17844785
]
David Smiley commented on SOLR-17192:
-------------------------------------
I saw that you listed my name first in CHANGES.txt, which is the position of
the person I think of as most responsible for making the work item happen.
Clearly, that honor goes to you Jason. I use this distinction when filtering
work items in CHANGES.txt to attribute work to me and my colleagues to see how
we contribute to Solr as lead contributors (vs more supporting roles).
> Maximum-fields-per-core soft limit
> ----------------------------------
>
> Key: SOLR-17192
> URL: https://issues.apache.org/jira/browse/SOLR-17192
> Project: Solr
> Issue Type: Sub-task
> Components: Schema and Analysis
> Affects Versions: main (10.0), 9.5.0
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Fix For: main (10.0), 9.7
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> Solr isn't infinitely scalable when it comes to the number of fields in each
> core/collection. Most deployments start to experience problems any time a
> core has upwards of a few hundred fields. Usually this doesn't exhibit
> itself right away. instead waiting until segment-merge or some other time to
> rear its head.
> Sometimes users hit this through intentional schema design. Often however,
> it happens "accidentally" due to (mis-)use of Solr's "dynamic fields" feature.
> We should add a configurable soft-limit, of the type described in SOLR-17191,
> to prevent users from unknowingly getting into this state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
