Discover: Sort automatically by _score if it makes sense

[timroes]

In Discover we sort by default by the timestamp. Some users suggested that it could make more sense sorting by default by _score if it makes more sense, e.g. that could mean if the user uses Lucene and uses boosting.

I am not sure if we should still implement some special behavior based on Lucene queries, or if there are similar scenarios for KQL, where we would determine sorting by _score makes more sense?

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[tamros]

I would at least have a a warning when someone change to lucene that is sorted by the time picker, because I think if you use fuzziness and boosting you might expect somehow the result set to be sorted by score desc and timestamp desc.

[myasonik]

Looks like we do this already for non-timeseries data.

Something that causes some confusion though is that we don't show the _score column in this case. This is especially confusing since 7.4 when we added multiple column sorting, sorting on another column will come up as a sub-sort to _score with no UI indicating that. (Whereas pre-7.4, it would replace the _score sort.)

CC @Bargs

[myasonik]

So I want to solve some of the confusion around initial sort order with the new DataGrid work going on in Discover.

This means I want to do two things:

• when using non-timeseries datasets, automatically show the _score column (similar to how we handle Time but less special case-y and just show _score as a regular field)
• show the default sort on page load (this would effect both Time and _score). This can be especially confusing with score where the default formatter rounds to an integer but cases where many round to the same number are easily possible (though this is also possible with Time with a custom formatter that drops seconds as well). Another side effect of this would be that Time and _score would be in the default URL (which I think is a good thing to more accurately reflect the state but maybe other disagree).

Without both of these fixes, the particularly bad issues comes up that to remove _score sort, the user needs to add _score, remove the sort, then remove _score. And that's assuming they figured out it was sorted on _score by default in the first place. (This only became an issue since 7.4 when we shipped multi-field sorting.)

These two changes would effect both the legacy table and the new DataGrid.

CC @timroes - thoughts?

[timroes]

I like the idea in general a lot, of making a distinction between time based indexes and non time based ones and apply the logic you suggested.

With regards to adding _score again, to remove sort, I think that's also tracked in #54345, and I in general wonder if we need a more generic solution there. Also in terms of a more specific solution: Should we maybe consider the default sort, not to stay when the user manually select a sort, and only start "stacking sort fields" for manual added fields, but not the implicit first field?

[kertal]

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.