Requested feature overview description.
To make random order, more like a shuffle. Currently random order does not work when multiple pages are returned since it will reorder them every time it's queried.

My suggestion is that every day (like an SQL event) each post is assigned a random number called 'order' for example, and then the table is indexed by this. When someone adds "order:shuffle" to their search query, it will run the query as normal, but then sort it by the before mentioned 'order' column.
Why would it be useful?
This would fast shuffling of many user queries that may return many values, with little CPU cost, it would also allow users to use pagination on shuffle queries and not ever see duplicates or missing values.

What part(s) of the site page(s) are affected?
Posts and any page that allows sorting

Misc notes
Creating the index would be near linear with respect to posts,, and it would only have to be done once a day (or whatever), and I imagine this query could be done 'in the background' or something.

There may exist better ways to do this, but this one is decent.
Also, the pagination would stuff up, if you were doing this at the time of day when the new 'order' was put in, but meh.

Why not just refresh the random load?

Furrin_Gok said:
Why not just refresh the random load?

Not sure what you're saying here, but you will get duplicates and miss posts if your query returns multiple pages of results.

E.g suppose you did a search and it returned 2 pages of stuff, you could see a post, then see it again on page 2, whilst another post which is supposed to be there was on neither. If you want to 'shuffle' the posts, but see all posts once and only once, there exists no real method of doing that.

Probably because people who search order:random don't intend to see every post in that search.

It is possible to do with seeded random sorting(EG: ORDER BY RAND(extract(epoch from now())%86400)), but random sorting is already slow enough on it's own.

Chaser said:
It is possible to do with seeded random sorting(EG: ORDER BY RAND(extract(epoch from now())%86400)), but random sorting is already slow enough on it's own.

Yes, but using the method I outlined, instead of sorting by a dynamic calculated field, you would rather build a key (once a day or whatever). And then Sorting by this Index, is very fast (Same speed as sorting by score, or favorites or similar)

With the only penealty of having to periodical reorder the key (which should be practical).

is about as close to this as I'm willing to go. Updating posts with random sequence ids each day is way too expensive, and this is a very niche feature.