[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165856#comment-14165856
]
Hoss Man commented on SOLR-6349:
--------------------------------
Side note...
one good bit of discovery that came out of my failed patch was a realization of
why the StatsComponent currently doesn't write out any stats values in some
cases -- as discussed in this comment in SOLR-6351...
https://issues.apache.org/jira/browse/SOLR-6351?focusedCommentId=14160658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14160658
{quote}
...
my thinking, was that:
* the behavior when hanging stats off pivots should mirror that of regular stats
* if you ask for a stats block , you should always get that block, so the
client doesn't have to conditionally check if it's there before looking at the
values.
* the included stat values matter even if no doc has the stats.field, becuase
one of the stats is in fact "missing" and that if you ask for stats, you should
be able to look at that missing count. (and it should match up with your doc
set size if the field is completely missing, etc...)
but looking at an example of this now, i see that for simple field stats (w/o
pivots), that's not even how it currently works – consider this URL using hte
example data...
http://localhost:8983/solr/select?rows=0&q=name:utf&stats.field=foo_d&stats.field=popularity&stats=true
...
{quote}
I found that the source of this behavior comes from this code in
StatsComponent...
{code}
if (isShard == true || (Long) stv.get("count") > 0) {
stats_fields.add(statsField.getOutputKey(), stv);
} else {
stats_fields.add(statsField.getOutputKey(), null);
}
{code}
...obviously if we're going to start making stats optional, we can't make the
response data conditional on wether "count" is greater then 0, because there
might not be a count.
So we'll need to revamp this, and i'm more and more convinced my comment in
SOLR-6351 is the right way to go...
{quote}
I thought (and still think) that the "correct" behavior for this query would be
to get a stats block back for those fields where things like min/max/mean are
"null", count==0, and missing=1 ... but that's not how it currently works.
{quote}
> 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___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]
