Нужны ли все поля документа с максимальным и минимальным временем выборки

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

Думаете ли вы про объём выбираемых данных или тянете сущность целиком просто потому, что так удобнее в ORM. За вопросом стоит проекция: какие колонки нужны на самом деле, чтобы найти документ с самым ранним и самым поздним временем.

Как отвечать

Начать стоит с уточнения, что делают с результатом. Если нужен сам факт «вот эти два документа», достаточно идентификатора и метки времени, а остальные поля дочитываются одним запросом по найденным id.

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

select id, created_at from documents order by created_at limit 1;

Широкие поля стоят особенно дорого: в PostgreSQL длинный текст и двоичные данные уезжают в TOAST и читаются отдельными обращениями, так что каждая лишняя колонка это лишний ввод и вывод.

В Java проекция задаётся на уровне запроса, а не после него: DTO через конструктор в JPQL, интерфейсная проекция в Spring Data, select new .... Ленивая загрузка помогает не всегда, и полагаться на неё как на замену проекции не стоит.

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

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

Ждут, что LAZY спасёт от лишних колонок. Ленивость связей работает через прокси, а для обычных полей @Basic(fetch = LAZY) требует байткод-энхансмента и без него молча игнорируется.

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