Sort ids query by order of ids passed in

[rightaway]

There's no good reason for ids query to return documents in an order other than the order of the ids that were provided. The ids are provided in an array, which is ordered, so the values should be returned as such. What's the benefit in surprising users in a negative way doing something order than what would be expected by default?

#3458 was closed years ago abruptly with no explanation, despite it continuing to be requested by many in the years after that. I'd like to open another issue so that it can be actually considered reasonably this time.

If you don't want to break the whatever order they're provided in, then an option that can be passed to the query activating this mode would be good. Although I don't see why it shouldn't be the default.

[elasticmachine]

Pinging @elastic/es-search

[jimczi]

There's no good reason for ids query to return documents in an order other than the order of the ids that were provided. The ids are provided in an array, which is ordered, so the values should be returned as such. What's the benefit in surprising users in a negative way doing something order than what would be expected by default?

That's not how search works. Ids queries are just one type of query that you can mix with other (boolean) to retrieve results. The default sort is by relevancy, which means that documents are sorted by their query score. If you're only searching for a couple of ids you can use the multi_get apis which will preserve the order and should be much faster than using a custom script sort and the ids query. Is there a reason why you cannot use the multi-get ?

[rightaway]

Limitations of multi-get api is described in the linked issue #3458 (comment).

[jimczi]

Yes, along with the reasons why we don't want to support this and the possible workarounds.
The ordering of documents in the response is controlled by the sort criteria. I understand that the _ids query can be thought differently since each id can match at most 1 document. Though this is the search API, not a multi get API, so I don't see why one query should dictate the behavior of the whole search. I would also add that even if we wanted to support this feature it would require a lot of thinking to make it work with the current design in a way that wouldn't be too surprising. It would be much easier for you to simply re-sort the hits in the response with the logic you want client side. This would also be much faster than the script sort solution because it requires to load the id field in the fielddata (we don't build doc_values on the _id field).

[cbuescher]

Looks like this is not something we're going to work on, so I'm closing this.

[markharwood]

@cbuescher - I think we are effectively working on this with the pinned query proposal