I have managed to produce a unit test that exposes this (albeit different 
to the data above).
The index is quite small - and the data fictional - so theres no problem 
sending you the index.

Here is a result I get - and we can see the sub-aggregations have higher 
counts than the parent:
{
    "sales_quotas": {
        "doc_count": 6,
        "shipmentDate": {
            "buckets": [
                {
                    "key": "Overdue",
                    "to": 1.3989024E12,
                    "to_as_string": "2014-05-01",
                    "doc_count": 2,
                    "nothingAllocated": {
                        "doc_count": 6,
                        "ME": {
                            "doc_count": 0
                        },
                        "NOT_ME": {
                            "doc_count": 6
                        }
                    }
                }
            ]
        }
    }    
}








On Tuesday, 6 May 2014 10:34:53 UTC+1, mooky wrote:
>
> I am using elastic 1.1.1.
> The index isn't huge (600m) - but it contains financially sensitive 
> data... will be too problematic legally to allow it offsite. I can try 
> anonymise the data - see if it can be reproduced that way - might learn 
> something about what is causing it.
>
>
>
>
>
> On Friday, 2 May 2014 14:34:21 UTC+1, Adrien Grand wrote:
>>
>> What version of Elasticsearch are you using? If it is small enough, I 
>> would also be interested if you could share your index so that I can try to 
>> reproduce the issue locally.
>>
>>
>> On Fri, May 2, 2014 at 12:07 PM, mooky <[email protected]> wrote:
>>
>>>  
>>> I havent been able to figure out what is required to recreate it.
>>> I am doing a number of identical aggregations (just different values 
>>> intentMarketCode 
>>> and intentDate
>>> Three aggregations give correct numbers - one doesnt.... I havent 
>>> figured why....
>>>  
>>>
>>> On Wednesday, 30 April 2014 14:13:00 UTC+1, Adrien Grand wrote:
>>>
>>>> This looks wrong indeed. By any chance, would you have a curl 
>>>> recreation of this issue?
>>>>
>>>>
>>>> On Tue, Apr 29, 2014 at 7:35 PM, mooky <[email protected]> wrote:
>>>>
>>>>> It looks like a bug to me - but if its user error, then obviously I 
>>>>> can fix it a lot quicker :)
>>>>>  
>>>>>
>>>>> On Tuesday, 29 April 2014 13:04:53 UTC+1, mooky wrote:
>>>>>
>>>>>>  I am seeing some very odd aggregation results - where the sum of 
>>>>>> the sub-aggregations is more than the parent bucket.
>>>>>>
>>>>>> Results:
>>>>>>     "CSSX" : {
>>>>>>       "doc_count" : *24*,
>>>>>>       "intentDate" : {
>>>>>>         "buckets" : [ {
>>>>>>           "key" : "Overdue",
>>>>>>           "to" : 1.3981248E12,
>>>>>>           "to_as_string" : "2014-04-22",
>>>>>>           "doc_count" : *1*,
>>>>>>           "ME" : {
>>>>>>             "doc_count" : *0*
>>>>>>           },
>>>>>>           "NOT_ME" : {
>>>>>>             "doc_count" : *24*
>>>>>>           }
>>>>>>         }, {
>>>>>>           "key" : "May",
>>>>>>           "from" : 1.3981248E12,
>>>>>>           "from_as_string" : "2014-04-22",
>>>>>>           "to" : 1.4006304E12,
>>>>>>           "to_as_string" : "2014-05-21",
>>>>>>           "doc_count" : *23*,
>>>>>>           "ME" : {
>>>>>>             "doc_count" : 0
>>>>>>           },
>>>>>>           "NOT_ME" : {
>>>>>>             "doc_count" : *24*
>>>>>>           }
>>>>>>         }, {
>>>>>>           "key" : "June",
>>>>>>           "from" : 1.4006304E12,
>>>>>>           "from_as_string" : "2014-05-21",
>>>>>>           "to" : 1.4033088E12,
>>>>>>           "to_as_string" : "2014-06-21",
>>>>>>           "doc_count" : *0*,
>>>>>>           "ME" : {
>>>>>>             "doc_count" : *0*
>>>>>>           },
>>>>>>           "NOT_ME" : {
>>>>>>             "doc_count" : *24*
>>>>>>           }
>>>>>>         } ]
>>>>>>       }
>>>>>>     },
>>>>>>
>>>>>>
>>>>>> I wouldn't have thought that to be possible at all.
>>>>>> Here is the request that generated the dodgy results.
>>>>>>
>>>>>>
>>>>>>     "CSSX" : {
>>>>>>       "filter" : {
>>>>>>         "and" : {
>>>>>>           "filters" : [ {
>>>>>>             "type" : {
>>>>>>               "value" : "inventory"
>>>>>>             }
>>>>>>           }, {
>>>>>>             "term" : {
>>>>>>               "isAllocated" : false
>>>>>>             }
>>>>>>           }, {
>>>>>>             "term" : {
>>>>>>               "intentMarketCode" : "CSSX"
>>>>>>             }
>>>>>>           }, {
>>>>>>             "terms" : {
>>>>>>               "groupCompanyId" : [ "0D13EF2D0E114D43BFE362F5024D8873"
>>>>>> , "0D593DE0CFBE49BEA3BF5AD7CD965782", "1E9C36CC45C64FCAACDEE0AF4FB91F
>>>>>> BA", "33A946DC2B0E494EB371993D345F52E4", "
>>>>>> 6471AA50DFCF4192B8DD1C2E72A032C7", "9FB2FFDC0FF0797FE04014AC6F0616B6"
>>>>>> , "9FB2FFDC0FF1797FE04014AC6F0616B6", "9FB2FFDC0FF2797FE04014AC6F0616
>>>>>> B6", "9FB2FFDC0FF3797FE04014AC6F0616B6", "
>>>>>> 9FB2FFDC0FF5797FE04014AC6F0616B6", "9FB2FFDC0FF6797FE04014AC6F0616B6"
>>>>>> , "AFE0FED33F06AFB6E04015AC5E060AA3" ]
>>>>>>             }
>>>>>>           }, {
>>>>>>             "not" : {
>>>>>>               "filter" : {
>>>>>>                 "terms" : {
>>>>>>                   "status" : [ "Cancelled", "Completed" ]
>>>>>>                 }
>>>>>>               }
>>>>>>             }
>>>>>>           } ]
>>>>>>         }
>>>>>>       },
>>>>>>       "aggregations" : {
>>>>>>         "intentDate" : {
>>>>>>           "date_range" : {
>>>>>>             "field" : "intentDate",
>>>>>>             "ranges" : [ {
>>>>>>               "key" : "Overdue",
>>>>>>               "to" : "2014-04-22"
>>>>>>             }, {
>>>>>>               "key" : "May",
>>>>>>               "from" : "2014-04-22",
>>>>>>               "to" : "2014-05-21"
>>>>>>             }, {
>>>>>>               "key" : "June",
>>>>>>               "from" : "2014-05-21",
>>>>>>               "to" : "2014-06-21"
>>>>>>             } ]
>>>>>>           },
>>>>>>           "aggregations" : {
>>>>>>             "ME" : {
>>>>>>               "filter" : {
>>>>>>                 "term" : {
>>>>>>
>>>>>>                   "trafficOperatorSid" : "S-1-5-21-20xxxxxx"<span 
>>>>>> style="color: #000;" class="styled-by
>>>>>> ...
>>>>>
>>>>>  -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "elasticsearch" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>>> msgid/elasticsearch/4ceceaaf-4fb8-4e54-97f4-c49fcbf9493d%
>>>>> 40googlegroups.com 
>>>>> <https://groups.google.com/d/msgid/elasticsearch/4ceceaaf-4fb8-4e54-97f4-c49fcbf9493d%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Adrien Grand
>>>>  
>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "elasticsearch" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/elasticsearch/3e7d8928-f76b-4358-97b9-3189e037006c%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/elasticsearch/3e7d8928-f76b-4358-97b9-3189e037006c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Adrien Grand
>>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/dda7db79-c31f-48c0-b137-955ba054a1b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to