Конфигурация УПП 1.3.23.1, платформа 8.2.15.294, клиент-сервер

Начали использовать ограничение на уровне записей по физ лицам. Все настроили, нужным образом работает. Понятно, что должна снизиться производительность при таком варианте. Как такового замедления работы замечено не было, кроме ситуации отбора по работнику в журналах документов (например, Документы по начислению зарплаты сотрудникам). Отбор выполняется правильно, но ждать приходится по 6 минут. При этом отбор по работнику в журнале документа конкретного типа выполняется быстро.
Вопрос. Что делать с таким снижением производительности?

быстро работают отборы только на индексированые поля ОСНОВНОЙ таблицы

Может имеет смысл включить индексирование у нужной графы в журнале?
Вообще странно получается, ведь для журнала в базе создается отдельная таблица, насколько я понял

(2)А у тебя в СУБД реиндексация происходит регламентно?

Регулярно. Средствами 1С

Хм.А почему не средствами СУБД?

(4) а ты уверен что 1с умеет это делать???

(3) и про обновление статистики тоже нужно делать, желатено несколько раз в день

В общем сделаю средствами SQL, обновление статистики не делал. Видимо надо.
В чем еще может быть проблема кроме как в БД?

(6)Делаем Autovacuum каждую ночь на PostgreSQL.Хотя вот в баглисте есть такое:
Зависает PostgreSQL 9.0 (сценарий Расчет себестоимости)
Проблема:
Причиной зависания является отсутствие актуальной статистики по таблицам, участвующим в запросе. Количество записей в этих таблицах сильно изменилось с начала транзакции (было 0 стало 140000). Autovacuum не видит этих изменений снаружи транзакции и статистика остается неактуальной.
Способы решения:
Установить в postgresql.conf значение параметра join_collapse_limit=1
Ожидается патч, который на основе анализа изменений будет запускать сбор статистики по таблице