Кстати на MS SQL (разных версий от 2008 до 2019) наблюдал аналогичное:
в запросе INNER JOIN и TOP N. Основное время запроса тратилось на Clustered Index Scan по одной таблиц (большой как по количеству рядов, так и по размеру данных в ряду).
По второй таблице был относитльно быстрый Index Seek.
Так вот, время выполнения от N не зависело, хотя при небольших N достаточное количество рядов должно было набираться уже в начале большой таблицы.
В execution плане был merge join, и если через опции форсировать nested loop join, то TOP отрабатывал на этапе JOIN, как ожидалось.
Время выполнения соответственно уменьшалось фактически в (размер большой таблицы)/N раз.
Вот такие чудеса.
