# Aggregated sorted search with top hits and paging - items missing **URL:** \ **Category:** Elasticsearch\ **Created:** [September 25, 2025, 1:37pm UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225 "2025-09-25T13:37:20Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![irkallacz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/irkallacz/32/145163_2.png) [@irkallacz](https://discuss.elastic.co/u/irkallacz)\ **Post date:** [September 25, 2025, 1:37pm UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/1 "2025-09-25T13:37:20Z")
My intend is to have paged list of all categories presented by cheapest product, sorted by price. I have search `terms` aggregation by product category, sorted by `min` aggregation on price: ```json "aggs": { "count":{"cardinality":{"field":"category_id"}}, "categories": { "terms": { "field": "category_id", "order": { "sorting": "asc" }, "include": { "num_partitions": 2, "partition": 0 }, "size": 10 } }, "aggs": { "fields": { "top_hits": { "size": 1, "sort": [ { "price": "asc" } ] } }, "sorting": { "min": { "field": "price" } } } }, ``` There are 32 categories total. So far everything work, bud when I change the `num_partitions` to 3, some of categories witch was there, are suddenly missing. Namely the one, witch have cheapest product and was on first place when there was only 2 partitions. I have no idea, what is going on there and why. Code itself is variation on [Terms aggregation | Reference](https://www.elastic.co/docs/reference/aggregations/search-aggregations-bucket-terms-aggregation#_ordering_by_a_sub_aggregation) witch seams to be basic stuff. Can someone please tell me, where the problem is and how to make it work as intended? Thanks a lot. ---
**Author:** ![john-wagster](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/john-wagster/32/139021_2.png) [@john-wagster](https://discuss.elastic.co/u/john-wagster)\ **Post date:** [September 26, 2025, 3:21am UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/2 "2025-09-26T03:21:18Z")
@irkallacz first off welcome! I’m not an expert on aggs. But my rough knowledge here and a quick review of the docs: [Terms aggregation | Reference](https://www.elastic.co/docs/reference/aggregations/search-aggregations-bucket-terms-aggregation#_filtering_values_with_partitions) suggests that when you increase `num_partitions` you are bucketing your categories into further partitions but then by specifying `partition` you are asking for only those categories in the first or `0th` partition. You’d need to make subsequent queries for the `1rst` and `2nd` partitions if you had set `num_parititions` to `3`. So it makes sense to me that you report missing categories as you increase `num_partitions` without querying for the other `partition`values. Let me know if that helps at all. ---
**Author:** ![Mark\_Harwood1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood1/32/101255_2.png) [@Mark\_Harwood1](https://discuss.elastic.co/u/Mark_Harwood1)\ **Post date:** [September 26, 2025, 7:09am UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/3 "2025-09-26T07:09:03Z")
Hi. Partitions should only be used when there are very large numbers of unique values (maybe millions or more). 32 unique values should work fine without partitions. ---
**Author:** ![irkallacz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/irkallacz/32/145163_2.png) [@irkallacz](https://discuss.elastic.co/u/irkallacz)\ **Post date:** [September 29, 2025, 7:48am UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/4 "2025-09-29T07:48:06Z")
Thanks for the response, but that is not the issue. I always ask for 0 partition (`"partition": 0`). And I have buckets sorted by price, so at first place should be same category. But when I change `num_partitions` to 3 instead of 2, at the first partition (0) at first position is something else. ---
**Author:** ![Mark\_Harwood1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood1/32/101255_2.png) [@Mark\_Harwood1](https://discuss.elastic.co/u/Mark_Harwood1)\ **Post date:** [September 29, 2025, 3:18pm UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/5 "2025-09-29T15:18:37Z")
> [@irkallacz](#): > > But when I change `num_partitions` to 3 instead of 2, at the first partition (0) at first position is something else. To be expected. Each category’s chosen partition number is hash-of-the-category-id modulo num\_partitions. If you change num\_partitions then you change 1. how many categories are in each partition and 2. which categories go in which partition. As I said before, if you only have a small number of unique categories you do not need to set num\_partitions - that is only required when you have millions of unique values and get errors. ---
**Author:** ![irkallacz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/irkallacz/32/145163_2.png) [@irkallacz](https://discuss.elastic.co/u/irkallacz)\ **Post date:** [September 30, 2025, 10:42am UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/6 "2025-09-30T10:42:02Z")
Categories are sorted by price of cheapest product. Even if there are different number of partitions, I assume that the order should be the same. And category with cheapest product should be on first partition (witch in my case is not). Or I am missing something? I know, that in my specific case, the partitions are not needed, I am just trying to understand how this work. ---
**Author:** ![Mark\_Harwood1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood1/32/101255_2.png) [@Mark\_Harwood1](https://discuss.elastic.co/u/Mark_Harwood1)\ **Post date:** [September 30, 2025, 2:34pm UTC](https://discuss.elastic.co/t/aggregated-sorted-search-with-top-hits-and-paging-items-missing/382225/7 "2025-09-30T14:34:11Z")
Distributed data can be the enemy of analytics. I added partitions to elasticsearch to solve worst-case scenarios like the one I call the “Elizabeth Taylor problem”. In this scenario we want to know who has been married the most often. Elizabeth Taylor was a Hollywood actress who married 8 times but she is not easy to find if we have millions of marriage certificates in our index and these are spread across many shards/nodes. If each of Elizabeth’s marriage certificates is stored on a different server then she appears no more remarkable than the millions of other names held on each node who only ever married once. That means each node has to stream a list of every unique name (even if they have only one marriage certificate) to a co-ordinating node to add up all the values. This co-ordinating node becomes a bottleneck and can throw a “too many buckets” error trying to squeeze all this data into memory. This is expensive and rather than trying to exhaustively analyze all data at once you could break it down into 26 requests - “which people with a surname beginning with ‘A’ married most”, then repeat for B, then C etc This is what partitioning does for you- it breaks one big job into N jobs to avoid resource constraints on heavy computations. It’s a compromise (your client may have to do the work to figure out the final most-married answer). The network and memory constraints introduce complications the same way the small boat constraint does in the classic “chicken, fox and the grain” problem. What seems simple becomes hard due to resource constraints