[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-6349:
---------------------------
Attachment: SOLR-6349.patch
bq. but i remember thinking the string,enum, and date code looked brittle ...
...looks i already fixed most of what i remember being worried about in my last
patch? reviewing this did however job my memory about SOLR-6682 - so i've
folded the patch from that issue into here
Updates since last patch...
* Incorporated SOLR-6682 in here to help ensure good test coverage of enum stats
* TestDistributedSearch
** beef up testing of stat subset permutations on other field types
** add some trivial sanity check asserts to the test queries added by SOLR-6682
* StatsComponentTest
** removed nocommit reminders to sanity check stat values when no values
available (haven't seen any complaints)
** cleaned up some bogus assert msgs from the SOLR-6682 patch
* StatsValuesFactory
** EnumStatsValues.updateMinMax
*** my previous code had a bug here using computeMin to update the max stat
* StatsField
** clean up some lingering nocommits - mostly related to javadocs
* add SHA1, LICENSE, and NOTICE for new commons-math3 dependency
...i think this is good to go .. going to do another total review of things and
aim to commit tomorow.
> LocalParams for enabling/disabling individual stats
> ---------------------------------------------------
>
> Key: SOLR-6349
> URL: https://issues.apache.org/jira/browse/SOLR-6349
> Project: Solr
> Issue Type: Sub-task
> Reporter: Hoss Man
> Attachments: SOLR-6349-tflobbe.patch, SOLR-6349-tflobbe.patch,
> SOLR-6349-tflobbe.patch, SOLR-6349-xu.patch, SOLR-6349-xu.patch,
> SOLR-6349-xu.patch, SOLR-6349-xu.patch, SOLR-6349.patch, SOLR-6349.patch,
> SOLR-6349.patch, SOLR-6349.patch, SOLR-6349.patch, SOLR-6349.patch,
> SOLR-6349.patch, SOLR-6349___bad_idea_broken.patch, make-data-and-queries.pl,
> make-data-and-queries.pl, make-data-and-queries.pl
>
>
> Stats component currently computes all stats (except for one) every time
> because they are relatively cheap, and in some cases dependent on eachother
> for distrib computation -- but if we start layering stats on other things it
> becomes unnecessarily expensive to compute all the stats when they just want
> the "sum" (and it will definitely become excessively verbose in the
> responses).
> The plan here is to use local params to make this configurable. All of the
> existing stat options could be modeled as a simple boolean param, but future
> params (like percentiles) might take in a more complex param value...
> Example:
> {noformat}
> stats.field={!min=true max=true percentiles='99,99.999'}price
> stats.field={!mean=true}weight
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
