шляпа какай-та ))

Где админы? Пора на инвайты переходить.

Подскажите, пожалуйста.
Есть реп, есть много-много записей.
Пагинатор не хочу туда втыкать в возвращаемое значение.
Записей реально много и считать их кол-во с наложенными фильтрами, джойнами и группировкой - боль.
Предположим, что буду реализовывать кнопку "показать еще".
return [$EntityList, $hasNext = false|true] - тоже в репе как-то стремно делать.
Как тут лучше поступить? Завести DTO возвращаемое из репа, в котором есть и лист и флаг наличия доп. страниц?

непонятно в чём проблема? В скорости выполнения запроса?

Ну, типа. ЗАчем ворошить count($paginator) всю бд, если на самом деле мне достаточно знать, что после, условно, 20 записей выбранных есть еще как минимум одна и можно показать кнопку "показать еще"

Технически, я могу у репа просто попросить не 20, а 21 и уже в контроллере отсечь.

Репу, по идее, не дОлжно знать, чего там в бд еще есть. Попросил записи - вот тебе записи. Сам их анализируй.

и сколько выполняется запрос на проде?

Да фиг его знает.
Я на этапе проектирования.

:)

Представим, что это - список заказов в админке. С выборкой за год.

Не парься преждевременными оптимизациями - потрать это время на написание понятного и простого кода

Кто то может дойти до конца (захочет?)?

Я понимаю что это не ответ на твой вопрос но всё же.
У меня в компании ребята написали собственную систему фильтров и состовления запросов.
Напиши и ты свою - это не сложно.
И я думаю правильные индексы и плоская таблица решит твою проблему с лярдами записей.

count($paginator) без разницы захочет-не захочет.
Он считает всё кол-во, исходя из наложенных addWhere, группировок и прочего.

Я про ui и кнопку "ещё"

А, типа. Хехе.
+1 есть всегда?)

Тоже есть подвох. Дофига дотошный админ может в фильтре так нафильтроваться, что у него останется 2-3 страницы заказов.

Если кол-во элементов в результате менбше лимита - нет.
Иначе да

Ну тоже, кстати, вариант.