The randomization they are working around is most likely > WHERE indexedColumn > RANDOM() LIMIT 10 That can be bound on RANDOM() performance or we can rely on

The randomization they are working around is most likely > WHERE indexedColumn > RANDOM() LIMIT 10 That can be bound on RANDOM() performance or we can rely on a seeded "non-random" PRNG to produce a random selection vector without running random() for every row. If that has a syscall into /dev/urandom for every row, then that sucks for sure & is not representative of the actual intention. In Apache Hive, we have a similar argument about unix_timestamp(), which was made deterministic, but stateful (MapReduce failure tolerance demands that if a task fails while running a query like > unix_timestamp() + n, the next attempt will produce an identical output, even-though some time has passed between the attempts). So for that, we do the unix_timestamp() replacement per-query, instead of per-row. I assume that's what was done here.