This is just a general query out of curiosity, but I’ve noticed whenever I sort my own observations by faves, the remaining non-favorited observations are just kind of sorted with no rhyme or reason. It’s very obviously not chronological, it’s not by IDs, not alphabetical.
Is there any rhyme or reason to the way the remainder are sorted? I’m curious!
tldr: yep, it indeed will not have order in current implementation.
it happens on tied non-zero favs groups too - basically the inat code has sql like ORDER BY cached_votes_total DESC NULLS LAST using single index for performance and nothing else for pure favourites sort aka no tie-breaking rules, so the postgres result order will be non-deterministic on ties whether they are tied at X value or zero favs you saw. It is technically correct sort but has unintended system effect as you see - the results order does fluctuate within the tied group (you can hard-refresh ctrl+shift+r and see for other vote ties), so since there is no explicit rule on tie-breaking, anything can happen at any stage -
if postgres picks multiple workers for that query
or bitmap heap scan as the favs index here is non-selective on zero favs group
or sorting algorithms
or in-memory order on observations fetched to sort/…
all of these can end up aiding subtle non-determinism for within group ordering.
I am not sure if these reorderings also happens across pages or its stable as the intention of user visiting next page is to see missed observations and if they get swapped into last page on same grp, that observation isnt encountered from such browsing unless one explicitly switches back and forth to see whether it happened then.