Есть запрос, пара левых соединений и группировка (слово РАЗРЕШЕННЫЕ не используется). В консоли разработчика запускается под разными пользователями, если у пользователя нет полных прав то время выполнения увеличивается в 10 раз. В выборке не указывается, что надо выбрать только разрешённых. Трассировку делать в скуле пока не хочется. Если это ожидаемое поведение, почему?

(0) Ожидаемое.
Слово разрешенные всего лишь приведет к тому будет красная ошибка или нет, если в результат попадут запрещенные записи ну и чуть чуть разные запросы.
Но сама причина не в слове РАЗРЕШЕННЫЕ, а в самом наличии РЛС,точнее его оптимальности

(0) И да это тот случай, когда это лучше увидеть в профайлере.
Посмотри текст с Разрешенные и без, посмотри план и тыпоймешь что я имел ввиду.

это актуальные типовым? и тебе не нужны разрешенные а нужны все и РЛС включен?

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

Суть такая, лаги у пользователей по всем фронтам, но основые в динамическом списке одного документа, естестественно, там установить привелигерованный режим нельзя на время запроса. Как подсказывают, можно отрубить параметры сеанса рубануть.
Делаю тестовый запрос, где просто выборка полей из документа "где" и пара условий. Полные права - мгновенно, пользователь с RLS 12 секунд. У RLS на скуле портяна в 580 строк, где делается 3 миллиона чтений и полторы тысячи записи, для запроса Админа же 160 чтений всего.
Добавляю нескольо прав пользователю, в какой-то момент тестовый зпрос начинает выполняться за полсекунды и 300 тысяч чтений из базы. Возвращаю исходные права - всё ещё за полсекунды. При этом, все действия пользователя как тормозили так и тормозят.
Чищу статистику, ребилд индексов, очистка кеша планов запроса. Тестовый запрос опять выполняется за 12 секунд.
Вывод - скуль не правильно строит план запроса по умолчанию. Что делать - Х.З.

>В типовых предусмотрен режим повышения привилегий в сеансе, чтобы запрос получил все данные без ограничений и на максимальной при этом скорости.

Запрос динамического списка выполняется в фоне, мне нужно повышать привилегии в самом запросе.

(4) можно перестать делать из динамосписка оперативный отчет.
вывалить эти данные в ТабДок или ТЗ, прибить к ним кнопку "обновить". исполнять запросы под привилегиями.

> можно перестать делать из динамосписка оперативный отчет.
Это не оперативный отчёт, это типовая форма списка, и там нет ничего криминального в коде запроса.

RLS тоже типовая

(4) Нормально скуль план запроса строит. Там просто портянка часто хреновая генерится и скуль делает что может.
Просто нужно рахзобраться с РЛС. Просто там РЛС не только на основную таблицу скорее всего,но и на ссылки в ней (получение представлений) Чем больше ограничений - тем больше таких херовин.

(8) Типовая <> оптимальная

(7) да и леший с ним, что типовая. попробуй свести запрос ДС к одной таблице.
(8) никто и не говорил, что рлс из коробки будет летать.

Что за конфа?

(7) да и леший с ним, что типовая. попробуй свести запрос ДС к одной таблице.
Если вы не читали, то я повторюсь: "Делаю тестовый запрос, где просто выборка полей из документа "где" и пара условий. Полные права - мгновенно, пользователь с RLS 12 секунд." До чего ещё надо свести такой запрос?

>Что за конфа?
1с Университет

если там свежая бсп, то там есть галочка "не тормозить"

БСП 3.0.2.233, достаточно свежая? Ща пороюсь.

(16) кстати, по поводу вывода в (4) // Вывод - скуль не правильно строит план запроса по умолчанию.

Это все на серверной базе и поэтому не так легко взять и заменить платформу. А версия платформы какая?

(16) Переходи на новый РЛС

>Это все на серверной базе и поэтому не так легко взять и заменить платформу. А версия платформы какая?
Платформу ставили последнюю, это первое что пробовали - никакого эффекта не дало, сейчас 8.3.14.1630

после обновления платформы неплохо бы сделать реструктуризацию

ну а на скуле - всякие регламенты типа обновления статистики

> ну а на скуле - всякие регламенты типа обновления статистики
Такое впечатление, что никто нихрена не читает: (4)
"Чищу статистику, ребилд индексов, очистка кеша планов запроса. Тестовый запрос опять выполняется за 12 секунд. "

(22) а (20)?

Да, тестирование и исправление и реструктаризация - проводились.

в документации галочка из (15) только к 3.1.2 https://its.1c.ru/db/bsp312doc#content:1976:hdoc
но вроде как она и раньше была (3.1 или даже 3.0), только не выведена в интерфейс.

https://i.imgur.com/WdVEWkp.png

(26) Спасибо за настройки, у нас нет выбора производительности. Проблема решена: проанализирован план запроса, построены нужные индексы, после этого всё стало норм. Виноваты ОЧЕНЬ кривые руки разработчиков типовой.

(27) Разработчик: СГУ-Инфоком
Студенты же писали.

(10) когда ктото пишет про тормоза ответ сводиться к двум вариантам
1. Если ты что то дописал - ну так это твой кривой код, из-за него тормозит, смотри как в типовой написано
2. Если ты ничего не дописывал (типовой код от 1С) - ну так код же универсальный, а поэтому не оптимальный. Нужно его полностью переписать

(29) Тормоза на типовом функционале и нет, его не надо полностью переписывать, там архитектурный просчёт, который очевиден для любого более менее опытного разрабочика: сразу на этапе разработки. Другой вопрос, что поиск таких мест - может быть не очевиден и весьма трудоёмок, потому что когда конфигурация уже написана, то причин может быть море. Собственно целая неделя боданий и ушла только потому, что не предполагались такие детские ошибки и искались серьёзные узкие места.

(26) спасибо, мил человек, что показал кнопку "НЕ ТОРМОЗИТЬ", которую так ждали пользователи, а то бы еще пол-года не увидел

С другой стороны, после ее включения ничего не поменялось.
Хорошенько выждал, пока "Обновление доступа на уровне записей" пройдет до конца по нескольку раз (== сходил на обед). Как до включения, так и после у пользователя один и тот же список "Безналичные платежи" открывается 24 секунды, а у пользователя с полными правами - за пол-секунды.
УТ-11.4.10.89, проблема с тормозами об рельсы в этом месте с самой ранней 11.4.1

(31) насилуй скуль, доп.индексы делай.

(31) ну тогда сравнивай запросы в профайлере план выполнения смотри... самый плохой вариант, когда пользователь почему-то решил отсортировать ДС по полю со ссылкой на справочник, на которой наложен RLS. И при этом на основную таблицу тоже наложен RLS.

вместо отбора, блеать.

на таком количестве тормозящих релизов можно было бы в тексте RLS разобраться и понять, что надо отключить или изменить
Может получится возвращать ссылки (не реквизиты) без условия RLS, т.к. сами по себе ссылки еще не читаемые данные.