Друзья!
Имеем УФ, дин. список с основной таблицей (вида "Документ") и произвольный запросом.
В запросе добавляю в поля статус документа через соединене с регистром сведений.
Документов в базе около 10 000, записей в регистре - около 100 000.
Вопрос: почему в файловом варианте при внутреннем соединении дин. список при каждом считывании данных обновляется ~60 секунд, в то время как при левом соединеии - 2-3 секунды? Сами запросы этого дин. списка выполняются ~0.5 секунды (с левым - быстрее на 100 миллисекунд).
Судя по тому, что в клиент-серверном режиме той же базы разницы между левым и внутренним соединением нет (дин. список обновляется за пол-секунды), делаю вывод, что оптимизатор файловой базы как-то не так трактует внутреннее соединение, либо файловый вариант по какой-то еще причине тормозит с выводом дин. списка.
Текст запроса примитивный:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ДокументПриемТехники.Ссылка КАК Ссылка,
    СтатусыДокументов.СтатусДокумента КАК СтатусДокумента
ИЗ
    Документ.ПриемТехники КАК ДокументПриемТехники
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПР_СтатусыАктовПриемаВРемонт.СрезПоследних(, ) КАК СтатусыДокументов
        ПО (СтатусыДокументов.Документ = ДокументПриемТехники.Ссылка)

динамический список дерево?

(1) видел твою тему v8: очень медленно работает динамический список
Нет, не дерево - плоский список (много гуглил и мистил перед тем, как создать тему).

попробуй так

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ДокументПриемТехники.Ссылка КАК Ссылка,
    СтатусыДокументов.СтатусДокумента КАК СтатусДокумента
ИЗ
    Документ.ПриемТехники КАК ДокументПриемТехники
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПР_СтатусыАктовПриемаВРемонт.СрезПоследних(, ) КАК СтатусыДокументов
        ПО (выразить(СтатусыДокументов.Документ,документссылка.ПриемТехники ) = ДокументПриемТехники.Ссылка)


а вообще проблема в слове "разрешеные"... релься в файловой версии работает отвратительно, в клиент сервере запрос выполняется в ХП а в файловой на клиенте...

Проверл мини-расследование по предложениям-предположениям из (3)
1. На пользователе с полными правами дин. список тоже тормозит (он тормозит у всех пользователей).
2. Без "РАЗРЕШЕННЫЕ" тоже тормозит у всех пользователей, включая ПолныеПрава.
3. У ролей тех пользователей, под которыми проверял, RLS'ов нет.
4. С использованием ВЫРАЗИТЬ для измерения регистра статусов тоже тормозит (пардон, что вначале сразу не упомянул, что в этом регистре тип измерения не составной - там только одна ссылка на ПриемТехники) у всех пользователей.

А теперь интересная подробность:
1. Замена внутреннего соединения на левое, как писал в (0), сразу помогает.
2. Без замены внутреннего на левое тоже можно обойтись: нужно переставить внутреннее соединение в конец (!!!) секции "ИЗ". Т.е. у меня там идут еще левые соединения с другими регистрами сведений, а в самом конце - внутреннее по статусу. И так тоже дин. список работает быстро!

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

(4) Ты потыкал в муравейник рукой, тебя обожгло и ты решил, что там живет огонь.

(5) а как еще можно объяснить тормоза при внутреннем соединении, идущем перед левыми (и отсутствие тормозов, если все соединения левые, либо если внутренние соединения идут после левых)?

(6) Объяснить можно переведя базу в sql и посмотря план запроса.

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

(8) Тормоза могут быть не видны вооруженным взглядом на sql.
Смотри планы запроса, файловая работает идентично ms sql.

(8) что-то вы не то курите. И ежу понятно, что при левом соединении тупо выводится весь список документов, поэтому всё быстро. А внутреннее соединение - это жесточайший отбор, может у вас в список попадает всего 200 документов из 10000. И так как там всё без индексов, чтобы собрать 2 документов на экране надо перелопатить половину базы.

(9) ок, спс, возможно посмотрю.
(10) "И так как там всё без индексов" // там - это где?