Вот это очень хороший и важный вопрос! Правда ответ будет довольно объемным, но просто дело очень важное, и понимание этого будет в дальнейшем очень важным плюсом. Здесь корень тянется из самого принципа построения постраничности: для постраничности требуется знать сколько всего результатов есть, удовлетворяющих условию, и какой limit устанавливается. К примеру, всего записей 100, лимит 10 — итого у нас 10 страниц.

К чему я это? К тому, что каждый раз при выполнении процессора на получение данных, выполняется два запроса. Первый считает общее кол-во записей, удовлетворяющих условию, а второй уже делает конечную выборку. Так вот, при разработке getlist-процессора для shopModx-а, этот момент учитывался, и было использовано клонирование объекта запроса.

https://github.com/Fi1osof/shopModx/blob/02152b36f2143902a4fb2099378b54f1699b1e63/core/components/shopmodx/processors/web/getlist.class.php#L41

Для чего это было сделано? Дело в том. что при поиске могут быть использованы различные сложные условия, плюс джоины различных таблиц и прочее. При этом это может быть нужно только при первичном поиске записей. А при окончательной выборке данных (со всеми колонками), это может и не понадобиться. В итоге, если вопрос стоит именно в поиске по TV, но не надо будет специально подставлять значения этого TV в конечный вывод, то лучше всего это делать на уровне метода prepareCountQuery().

https://github.com/Fi1osof/shopModx/blob/02152b36f2143902a4fb2099378b54f1699b1e63/core/components/shopmodx/processors/web/getlist.class.php#L80

Переопределяем его, добавляем innerJoin() таблицы с условием и все. На выходе процессор выполнит поиск всех удовлетворяющих условию записей, и подставит их ID-шники в конечный запрос выборки.

https://github.com/Fi1osof/shopModx/blob/02152b36f2143902a4fb2099378b54f1699b1e63/core/components/shopmodx/processors/web/getlist.class.php#L70

При этом в окончательном запросе джоина этой доптаблицы не будет, так как в ней нет необходимости, у нас уже есть ID-шники искомых записей.