День добрый!

Делюсь впечатлениями.

Односекундный запрос превращается в семиминутный одной, казалось бы, оптимизирующей его строкой:

ВЫРАЗИТЬ(МойРегСв.ЛюбаяСсылкаТут.Организация КАК Справочник.Организации)

Да как так-то???

(0) ага изо всех щелей так оптимизация и прет, ЛюбаяСсылкаТут - как я это дохера различных документов

(1) Результат запроса кодом обрабатывается за туже одну секунду, если не догадался

(2) Потому что тип известен.

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

ВЫРАЗИТЬ надо МойРегСв.ЛюбаяСсылкаТут., а не то что после точки идёт. У тебя по сути никакой оптимизации, происходит обращение через точку(неявное соединение) к реквизиту составного типа, то есть идет джойн со всем чем только можно.

(4) Так ты подумай! И расскажи, что там с соединениями не так, и чем это отличается от построчной обработки результата запроса без выборки Организации, а выбором её кодом языка - это 355 запросов друг за другом. Запросы в цикле слышал?

(5) Логично, да. Выразить - индексация требует, но не суть.

те запрос
МойРегСв.ЛюбаяСсылкаТут.Организация
за 1 сек отрабатывает?

(8) Нет, только МойРегСв.ЛюбаяСсылкаТут

(8) + Цикл Выборка.ЛюбаяСсылкаТут.Организация - на весь результат запроса (355 строк)

(9) те выборку через точку от любой ссылки ты называешь оптимизацией?

Ты весь текст запроса давай, а то окажется что дело не в выразить

(6) Ещё раз - у тебя в запросе тип "ЛюбояСсылка" - не известен, какой будет. И оптимизатор джойнит все таблицы, которые там могут быть. При чем даже те, которые не содержат реквизит "Организация".
Из-за этого время и растет.
А когда исполняется код, то он делает селект на одну таблицу и получает реквизит "Организация".

Чтобы этого не было - сам присоедини нужную таблицу и бери Оргиназцию оттуда, а не из реквизита.

(12) Там больше ничего нет, только поля МойРегСв

(13) Вот почему "на одну", если поле составное в результате? В запросе 100+ соединений самому рисовать, что ли?

А что реквизит "Организация" регистра сведений может быть не равен справочнику "Ораганизации"?

В смысле тип реквизита

(14) Агась.

Да тоже не понятно... всё равно будет 100+ соединений, хоть вручную выражаю любую ссылку на каждый содержащий Организацию тип...

(14) ты текст запроса то дай

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

Оптимищация - это исскуство

(15) Конструктор ругается там, если нет Выразить и есть Индексировать, т.к. реквизит выбирается из всего что только можно, значит может получиться любой результат и NULL может быть

(18) ага, полюбому.

Как я понимаю всю красоту твоего запроса ты нам не покажешь, только кусочную оптимизацию?

Хотелось-то без кода обойтись, а то выбрал, выгрузил, заполнил, в запрос обратно загрузил... красиво, конечно, кратко потому что, но дичь какая-то

(24) Из красоты - там лишь эта строка. Остальное МойРегСв.*

(26) у некоторых понятие красоты может быть отлично от вашего - явите миру свою Запросю

(27) Читать (26) до просветления

(0) Покажи полный текст до и после.

В (5) уже все сказано правильно. В (0) чушь слоновья, а не оптимизация.

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

(29) до "оптимизации":
ВЫБРАТЬ
    МойРегСв.*
    МойРегСв.ЛюбаяСсылкаТут
ИЗ
    РегистрСведений.МойРегСв КАК МойРегСв

после
ВЫБРАТЬ
    МойРегСв.*
    ВЫРАЗИТЬ(МойРегСв.ЛюбаяСсылкаТут.Организация КАК Справочник.Организации) КАК Организация
ИЗ
    РегистрСведений.МойРегСв КАК МойРегСв

вроде так, судя по постам ТС

Правильно должно быть

ВЫБРАТЬ
    МойРегСв.*
    ВЫРАЗИТЬ(МойРегСв.ЛюбаяСсылкаТут КАК ТипНужнойТаблицы).Организация  КАК Организация
ИЗ
    РегистрСведений.МойРегСв КАК МойРегСв

Если типов таблиц несколько, то делаем объединением.

(31) Всё что за секунду выполняется - нет смысла даже пинать, сколь бы неоптимально, избыточно или неправильно писано - только время тратить.

(33) Вот это, как раз, пример "чуши слоновьей". Завтра добавится новый тип данных - переписывать будете?

(34) собирай текст запроса программно

(34) Это тебе не фузина https://its.1c.ru/db/metod8dev#content:5842:hdoc
"Получение данных через точку от полей составного типа", кури пока легкие не почернеют

(34) Либо переписывать либо (35)

(35) Слишком много текста. Не люблю я это))
Изменение запроса может затронуть точку входа модификации программной части и... короче - много думать там надо. В моей задаче - избыточно много думать над обработкой 355 строк.
В общем - запросы в цикле - наше всё! )))))))))))))))

А где односекундный запрос?

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

(40) А может стартап загнется и тогда секунда превратится в ноль)
Преждевременная оптимизация далеко не всегда оправданна, хотя перфекционисту с этим свыкнуться и тяжело бывает

(41) Как минимум стыдно перед коллегами, такое чудо "оптимизации" показывать.

(42) а он напишет что код не оптимизирован, "надо будет потом доделать" :)

Да-ДА-да! Ещё и напишу КАК именно доделать и отдам в работу)))))

(42) Может у него тип организации может принимать разные значения, вот и выражает его)

Если, как правильно было выше сказано, "стартап не загнётся". А то десятки обработок/очётов "очень нужных и важных" так и валяются грузом бесполезным

да он обыкновенный балабол, как вы сразу не догадались