# Aggregations query timeout and cancellation

**URL:** https://discuss.elastic.co/t/aggregations-query-timeout-and-cancellation/163791
**Category:** Elasticsearch
**Created:** [January 10, 2019, 5:22pm UTC](https://discuss.elastic.co/t/aggregations-query-timeout-and-cancellation/163791 "2019-01-10T17:22:52Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)
#### Post date: [January 10, 2019, 6:23pm UTC](https://discuss.elastic.co/t/aggregations-query-timeout-and-cancellation/163791/2 "2019-01-10T18:23:52Z")

</div>

I may be wrong on this but I recall that some aspects of a query are tight loops that are deliberately **not** interrupted because they are building data structures that are of use to all queries, not just the current one. The `global ordinals` for example need to be re-built after a refresh and if a query starts that process I think it may not be timed out because the resulting cache will benefit other queries. That certainly used to be the policy when loading the field data cache.

If global ordinals are the issue ([see example](https://discuss.elastic.co/t/global-ordinals-performance-and-size-on-heap/158320/7?u=mark_harwood) ) then it might be worth avoiding them through the use of `"execution_hint":"map"` if your query matches modest numbers of terms.

---

_[View the full topic](https://discuss.elastic.co/t/aggregations-query-timeout-and-cancellation/163791)._