Всем добрый день!!!
Подскажите как можно оптимизировать работу RLS? Есть динамический список с более чем 10000 записей. У пользователя стоит RLS на чтение такого типа «ГДЕ Ссылка В(&ДоступныеГруппыДоступаРесурсов)».  ДоступныеГруппыДоступаРесурсов это параметр сеанса который заполняется при запуске базы, данные получаются запросом, не сильно большим, но требующим использование виртуальных таблиц.
От пользователей поступила жалоба на медленную работу списка и нужно что-то  сделать, от RLS отказаться нельзя :( У кого-нибудь есть идеи как оптимизировать RLS, если да то поделитесь пожалуйста

>>ДоступныеГруппыДоступаРесурсов это параметр сеанса который заполняется при запуске базы, данные получаются запросом, не сильно большим, но требующим использование виртуальных таблиц.

это не влияет на дин. список

ДоступныеГруппыДоступаРесурсов насколько много там значений?

(1) я понимаю, просто описал ситуацию, и чтобы было понятно что нельзя перейти на RLS типа ГДЕ Ссылка В(#ДоступныеГруппыДоступаРесурсов) т.к. необходимы вирт. таблицы

"в" или "в иерархии"?

(2) Зависит от пользователя, но в самом плохом случае ~ 10000

(4) Для вычисления параметра используются "в иерархии"

Попробовать заменить В(...)  на соединение с регистром сведений, куда и писать доступные значения вместо параметров сеанса.

(7) РС сведений добавлять не очень хочется, потому что RLS не для всех пользователей. У некоторых пользователей есть просто права на чтение без RLS.

(0)смотри какой запрос исполняется СКЛом, думай

(0)
Нужно понимать , как работает динамический список -
он выбирает данные по индексу, в основном - по коду или наименованию для справочников.
Соответственно вместо ДоступныеГруппыДоступаРесурсов
ДоступныеГруппыДоступаРесурсовКод - те же ссылки ввиде кода
условие
«ГДЕ Код В(&ДоступныеГруппыДоступаРесурсовКод)»
И сортировка только по коду

(10) Код не всегда уникальный, а ссылка это аналог УникальногоИдентификатора и он всегда уникален в рамках одного справочника.
Кстати забыл сказать, что это динамический список у справочника.

(11)
Вы уже сами смотрите чтобы Ваш Rls попал в индекс сортировки
Я только примерно дал

(8) Ты сам конечно смотри, но перед тем как наложить фильтр в запросе по параметру сеанса, имеющему тип значений массив - 1С передает эти данные СУБД, они впоследствии собираются в таблицу операциями constant scan. Трудозатраты растут пропорционально количеству строк из которых таблица формируется. Можно обойтись без промежуточной передачи данных, если их хранить в СУБД, например в регистре сведений с двумя измерениями:

Пользователь / Группа Доступа Ресурсов

в RLS выбирать не из параметра сеанса, а из физической таблицы в БД.

Получается что быстрее было бы если использовать РС типа (Ресурс: Пользователь; Измерение: Группа Доступа Ресурсов) а РЛС переделать на ГДЕ Ссылка В(#ДоступныеГруппыДоступаРесурсов) ДоступныеГруппыДоступаРесурсов - Это шаблон из этого РС?

(14) Как то так:

ТекущаяТаблица
ИЗ
#ТекущаяТаблица КАК ТекущаяТаблица
ГДЕ
ТекущаяТаблица.Ссылка В
(ВЫБРАТЬ
  ОграничениеДоступа.ГруппаДоступа
  ИЗ
  РегистрСведений.ОграничениеДоступа КАК ОграничениеДоступа
  ГДЕ
  ОграничениеДоступа.Пользователь = &ТекущийПользователь)

В регистре ОграниченияДоступа хранишь списки доступных групп по пользователям.
Пользователь и ГруппаДоступа должны быть измерениями!!Первым идет Пользователь, а потом Группа доступа!! Тогда получишь кластерный индекс, позволяющий мгновенно выбирать все группы доступа пользователя. Без передачи их с сервера 1С на сервер СУБД.

А вообще ты уверен что именно в РЛС проблема?

(15) Да, если у тебя группа доступа, в справочнике который ты фильтруешь по РЛС находится не в реквизите "Ссылка" (это пример) то этот реквизит должен быть проиндексирован.

(15) Да проблема в РЛС, т.к. если просто право на чтение то все работает ОК.

Похоже что кроме РС ничего придумать не получиться.
Ребята большое спасибо за советы, вы мне очень помогли!!!

Есть еще вариант, если данные только из группы доступа - использовать источник для таблицы проиндексированную "группу доступа" типа регистра с левым соединением к уже справочнику.
Т.е. будет динамический список источник - произвольный запрос

Небольшой геморрой с оформлением

А вообще 10 000 записей в справочнике это вообще не о чем.
Пол сек работы запроса для полной выборки

(0) еще вариант, не изобретать велосипед и использовать подсистему Управление доступом из БСП

Переделал заполнение параметра и изменил RLS
ГДЕ Не (Не (Владелец В (&ДоступныеГруппыДоступаРесурсов)) И Не (Ссылка В(&ДоступныеГруппыДоступаРесурсов)))
Теперь получается в параметре всегда 1-3 значения.

Как вы думаете то что я использую Не (Не [Условие1] И Не [Условие2]) вместо Условие1 Или Условие2 дает какой-то бонус по скорости?

Если не ошибаюсь в запросах рекомендуют не использовать ИЛИ в ГДЕ потому что это равносильно разбиению на два запрос с ОБЪЕДИНИТЬ ВСЕ

(6) проблема именно в этом.

(23) вторая часть наоборот - рекомендуют использовать два запроса с объединить, ибо индексы и вся фигня, которая инкому не интересна

нужно регламентно (или при записи или еще как, например обновлять параметр сеанса) переделывать иерархический список в плоский и в шаблонах уже его использовать