С каким максимальным количеством таблиц приходилось писать запросы в PostgreSQL?

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

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

Как отвечать

Назовите порядок величины честно и сразу переходите к примеру: какая была задача, какие таблицы участвовали, какие типы соединений и почему. Детали, которые показывают опыт:

• зачем внешнее соединение там, где оно есть, и что произойдёт с количеством строк при соединении по неуникальному ключу;
• как считали агрегаты: подзапрос, оконная функция или группировка, и почему выбрали именно это;
• как смотрели план через explain (analyze, buffers) и на что глядели в нём: расхождение оценки с фактом, способ соединения, чтение с диска.

Стоит упомянуть, что у планировщика есть предел перебора порядка соединений: начиная с некоторого числа таблиц он перестаёт рассматривать все варианты и подключает генетический оптимизатор, поэтому на больших запросах порядок таблиц в тексте начинает влиять на план. Ради такого знания вопрос обычно и задают.

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

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

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

Ставят условие по правой таблице в where вместо on. Внешнее соединение при этом молча становится внутренним, и строки без пары пропадают из отчёта. Ошибка тихая: запрос работает, данные неполные.

Боятся соединений и дробят запрос на несколько, дособирая результат в коде. Получается лишний трафик и обращение к базе в цикле, что почти всегда медленнее одного запроса с подходящими индексами.