Сколько теоретически строк может вернуть SQL-запрос?

Что проверяют

Понимаете ли вы, что размер результата не ограничен объёмом исходных таблиц. Инженеру данных это нужно не для эрудиции: ровно на этом ломаются выгрузки и витрины, посчитанные из расчёта «строк будет примерно столько же, сколько в источнике».

Как отвечать

Теоретически неограниченно, и стоит назвать механизмы:

• соединение умножает: декартово произведение двух таблиц по миллиону строк даёт триллион;
• генераторы создают строки из ничего, например generate_series или таблица чисел;
• рекурсивный CTE без условия выхода не остановится вовсе и будет порождать строки, пока запрос не убьют или пока не кончится место под временные файлы.

Отсюда практический вывод, ради которого вопрос и задают: объём результата оценивают до выполнения, а не после. Смотрят план через EXPLAIN и ожидаемое число строк, ставят LIMIT на время разведки, выгружают курсором или порциями по ключу вместо одного чтения всего в память. Перед соединением проверяют уникальность ключа справа: незаметное размножение строк это самая частая причина, когда витрина вдруг выросла в несколько раз вместе со всеми суммами в ней.

Ограничения, конечно, есть, но не там, где их ищут: таймаут, место под сортировку, память клиента и настройки драйвера, а не «максимум строк в СУБД».

Где спотыкаются

Отвечают числом: называют предел размера таблицы или максимум строк в файле. Спрашивали про результат запроса, а он может быть больше любой участвующей таблицы.

Считают, что LIMIT 10 всегда дёшев. С сортировкой по неиндексированной колонке или с группировкой движок сначала посчитает и упорядочит всё, а отрежет десять строк в самом конце.

Забывают про принимающую сторону. База отдаёт поток строк спокойно, а падает скрипт, который сложил их в список в памяти. Лечится серверным курсором и обработкой пакетами, а не увеличением памяти на машине.