[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171405#comment-14171405
]
Tomás Fernández Löbbe commented on SOLR-6349:
---------------------------------------------
What about doing something like this:
StatsFields knows about the stats to calculate and the stats include in
response.
For the basic “standalone” statistics, those sets are equal, but when a
statistic requires others, the “calculate” set includes the depended stats.
All stats in the “calculate” set are calculated.
All stats in the “include in response” set are responded.
In the case of a shard request, all stats in the “calculate” set are also
included in the response.
StatsField gets the local params from the request, the StatsValues ask the
statsField instance before calculating a stat / including in the response.
The bad part of it is that all the stats need the
{code:java}
if (statsField.calculateStat(X)) {
X = calculateX()
}
{code}
The good part is that we don’t need to create classes for every single stat,
that may have to be generic in some way depending on the field type.
I’m uploading a patch with the idea, it’s not even close to complete, just to
show the idea (see only the NumericStatsValues implementation).
There are tests failing in StatsComponent that I haven’t looked at yet.
> 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___bad_idea_broken.patch
>
>
> 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]
