<p dir="auto">Documents of different types tend to have different fields, which can lead to problems of sparsity when documents are stored in the order that they were indexed.  If we sort documents by type, then missing values (eg in doc values or norms) can be represented very efficiently.</p>
<p dir="auto">On merge, documents should be sorted by type (assuming there is more than one type).  Additionally, for certain use cases, it can make sense to apply a secondary sort (eg on timestamp). This secondary level should be customizable per index, and should probably be dynamically updatable (although it would only have effect on later merges).</p>
<p dir="auto">Relates to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="51553271" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/8870" data-hovercard-type="issue" data-hovercard-url="/elastic/elasticsearch/issues/8870/hovercard" href="https://github.com/elastic/elasticsearch/issues/8870">#8870</a></p>
<p dir="auto">Lucene has index-time sorting and early query termination capabilities. It would be nice to integrate it into Elasticsearch in order to speed up queries whose sort order matches the index order. This <a href="https://speakerdeck.com/elasticsearch/index-sorting-with-lucene" rel="nofollow">presentation</a> contains some information about these features and their implementation in Lucene.</p>