-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Inaccurate values when calculating SUM or AVG aggregations #29345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Pinging @elastic/es-search-aggs |
@aurimasplu I have not been able to reproduce this bug. I tried with the following script which is based on the information you provided but with a few modifications to get it to work (your query uses a
|
Hi @colings86 , thanks for quick answer. Here is whole index mapping:
|
Oops I forgot to paste the script. Here it is:
I think the problem will come down the floating point rounding since your fields are I'm going to close this for now assuming that your issue will be fixed when you remap to a long field type but please comment if that doesn't solve your problem and we can look into this more |
Remapping to long worked as a charm, now sum and avg are calculated as expected. @colings86 thanks a lot for your help :) |
Uh oh!
There was an error while loading. Please reload this page.
Elasticsearch version : 6.1.1-1
Plugins installed: X-pack
JVM version: java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.x86_64
OS version : RHEL 7.4
Description of the problem including expected versus actual behavior:
When running sum or avg aggregations within terms aggregation getting inaccurate results.
Steps to reproduce:
I run this query:
and get this response:
When calculating output by myself from hits section I get that SUM of ifHCInOctets fields is 2013459245392 but when elastic calculates its SUM aggregation result is 2013459218432 which is lesser by 26960.
I also tried adding various sorting or removing child element- result always remained inaccurate. Same problem appears with avg aggregation.
The text was updated successfully, but these errors were encountered: