(RLS по физлицам) Сильное падение производительности в УПП при переходе с платформы 8.2 на платформу 8.3

Здравствуйте.

Имеется база Управление производственным предприятием, редакция 1.3 (1.3.86.2), работающая на платформе 8.2.19.80. Клиент-серверный вариант, PostgreSQL.

В данной базе включено ограничение доступа на уровне записей(RLS) по: Контрагентам, Физическим лицам, Складам, Подразделениям, Подразделениям организаций, Номенклатуре.

Работали на платформе 8.2 лет 5. Возникла необходимость перейти на платформу 8.3. Перешли на 8.3.8.1933. После перехода в базе стало невозможно работать расчетчикам зарплаты. Документы (например "Невыходы") расчитываются по часу, а может и больше(на платформе 8.2 несколько секунд). Путём экспериментов выяснил, что проблема конкретно в ограничениях по виду объекта "Физические лица". Если убрать этот вид ограничения, то всё работает отлично.

Решил поэксперементировать дальше:
У определенного пользователя убрал все группы доступа кроме например "Литейный цех".
В этой группе доступа поставил только ограничение по физлицам.

В итоге на платформе 8.2 например документ "Невыходы" с двумя записями рассчитывается секунд 10, а на платформе 8.3 более 2-х минут.

В файловом варианте разница менее заметна, но на 8.2 опять же документ рассчитывается быстрее чем в 8.3.

С чем может быть связана эта проблема? Неужели на платформе 8.3 механизм RLS работает настолько по другому, что возникает такая разница в производительности?
P.S.: Пришлось вернуть базу обратно на платформ
8.2 до выяснения причин происходящего.

А перешли на клиент-серверную 8.3?

Pin Occio,Да. Конечно

Иван,
а к физическим лицам не присоединены какие-нить файлы со сканами паспортов, СНИЛС, ИНН?

В каталоге по POSTGRESQL есть неисправленные ошибки
К УПП у меня нет доступа, но в-общем, можно судить, что там их колбасит.
В своё время, колбасило именно платорму, не буду глубоко копать
Вот некоторые цитаты из каталога

• Замедление стандратных отчетов при использовании СУБД PostgreSQL.
  Код ошибки: 10173424
  Код(ы) обращения: SW1114807
  Статус: Исправлена в будущей версии Зарегистрирована: 24.01.2017
  Исправлена: "Бухгалтерия предприятия, редакция 3.0", версия 3.0.48 -
  Описание:
  В стандартных отчётах при работе пользователя с ограниченными правами (доступ не ко всем организациям) наблюдается замедление работы операций, использующих представление организации. Ошибка зафиксирована при использовании СУБД PostgreSQL.
• Внешний источник данных PostgreSQL
  Код ошибки: 10162331
  Код(ы) обращения: SW1022005
  
  Статус: Исправлена в выпущенной версии Зарегистрирована: 05.05.2016

  Исправлена: "Технологическая платформа", версия 8.3.9.1818

  Описание:
  
  В клиенте, запущенном в CentOS 6.5, при выполнении запроса к внешнему источнику данных PostgreSQL или в конфигураторе при вызове конструктора таблиц источника происходит ошибка
  Invalid byte secuence for encoding "UTF": 0xe0 0x81 0x93
• Внешний источник данных PostgreSQL
  
  Код ошибки: 10159942
  Код(ы) обращения: SW1009647
  
  Статус: Исправлена в выпущенной версии Зарегистрирована: 10.03.2016
  

  Исправлена: "Технологическая платформа", версия 8.3.8.1652

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

А вот ошибки, при поиске по физическ* лиц*

• 
  
  Ошибка 00-00108005
  
  
  
  Код ошибки: 00-00108005
  
  Статус:  На рассмотрении Зарегистрирована: 10.02.2017
  
  Описание:
  
  Необходима отдельная роль прав, чтобы ограничить доступ пользователей к данным Физического лица (Место жительство, Прописка ,Паспорт ,и т.д.). При этом необходим доступ к самому списку Физических лиц.
  
  
  
• 
  

Pin Occio, когда то к физическим лицам были присоединены файлы фотографий. Но примерно год назад я удалил все прикрепленные фотографии, т.к. перестал сниматься бэкап базы (ошибка Out of memory). Проблема была в справочнике "ХранилищеДополнительнойИнформации". Я групповой обработкой у этого справочника значению поля "Хранилище"(именно там и хранились двоичные данные) присвоил значение Ложь, тем самым очистил базу от картинок. База тогда сильно уменьшилась в размерах и начала выгружаться снова.

На субд ms sql 2005, явно выраженных, различий по скорости между платформами не наблюдается (применительно к упп 1.3). делайте выводы.

Pin Occio,по поводу ошибки 00-00108005: она относится к платформе или к какой то конфигурации? А то я перешел по ссылке, а там не видно к чему относится эта ошибка.

Igor_Orlov,понятно. Спасибо за инфу

Речь идёт о применении клиент-сервера на POSTGRESQL
Эту связку постоянно колбасит
Не написано - к чему она относится
Я дословно скопировал

Pin Occio,понял. Спасибо