Был ли у кого прецедент сравнения полей в запросе с ориентированием на скорость обработки?
буквально, нужно выбирать результат сравнения "реквизит1=реквизит2 как поле1" с типом булево.
кроме как выбор-когда, есть что-то интереснее?
тип реквизитов всегда идентичен.

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

(0) Почему выбор замедлит?

Чего это он замедлит? Тоже что и обычное "если" только языком запроса

дык, выбор когда - операция раз, сравнение - операция два
или не так?

(3)Ну ты еще такты процессора посчитай.

(3) тогда храни результат сравнения в базе. и регламентно обновляй

я сужу по аналогии с обычным если, какой смысл использовать конструкцию:
Если а=б тогда Истина; иначе Ложь; КонецЕсли;

(6) смысл в том, что другой у тебя нет

(7) так вопрос и был, есть ли альтернатива?
вне запроса я буду использовать конструкцию "результат = (а=б)", в запросе конкретно эту конструкцию использовать - не получается

(8) ну так условие пишет
выбор когда а=б тогда истина иначе ложь конец

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

да куда быстрее. ты с языком sql знаком ? есть там другая альтернатива ?

Проиндексируй реквизиты. Проиндексируй поля временных таблиц, если есть.

(11)
есть.
реляция с таблицей

1. Альтернатива в СКД вычисляемое поле. Но я сильно смоневаюсь, что оно будет быстрее, поэтому при данной постановке задачи не подойдет.
2. Выбор в данном случае на скорость повлияет не сущестенно.

тк 1с8 может использовать несколько субд,
для обсуждения такой странной отимизации
уместно указать платформу 1с и тип исполнителя запроса (субд)
включая ос.

(15) скуль, 8.2.18, 64х
с самим скулем знаком слабо, таить нечего, посему размышляю в рамках обычного кода с поправками на правила и опыт оптимизации.
в данный момент запрос реализован через "выбор-когда", но, мне кажется, это не самое оптимальное решение.

(16)Другого нет.

(3)
>>выбор когда - операция раз

простите, что за операция?

(18) это придирки? могу назвать итерацией, это сильно меняет контекст, или в приведенном примере, действительно, неверная логика?

(19) основные затраты сервера (если там конечно не рекурентная хранимая процедура) это чтение, запись и "борьба транзакций"

ускорять запрос в данном случае неуместно

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

Выложи запрос

Запрос динамический, в кратце: две таблицы значений грузятся во временные, соединяются полным соединением по прямому сравнению одного поля и сверяется равность реквизитов.
структура таблиц идентичная за исключением одной колонки, являющейся ссылкой (только у одной из таблиц), остальные поля - примитивных типов (строки есть, но, естественно, ограниченной длины) колонок в таблице от пары-тройки до нескольких десятков.
сверяются и выбираются все поля, кроме ссылки.

запрос в общем виде следующий
ВЫБРАТЬ
|    ВТ_Местная.Ссылка,
|    ВТ_Местная.ИД" + ВставкаВЗапрос1 +"
|ПОМЕСТИТЬ ВТ_Местная
|ИЗ
|    &ВТ_Местная КАК ВТ_Местная
|;ВЫБРАТЬ
|    ВТ_Удаленная.ИД" + ВставкаВЗапрос2 +"
|ПОМЕСТИТЬ ВТ_Удаленная
|ИЗ
|    &ВТ_Удаленная КАК ВТ_Удаленная
|;
|Выбрать
|ВТ_Местная.Ссылка"+ВставкаВЗапрос3+"
|ИЗ
| ВТ_Местная как ВТ_Местная Полное соединение ВТ_Удаленная как ВТ_Удаленная ПО ВТ_Местная.ИД= ВТ_Удаленная.ИД

где третья вставка, сейчас, следующего вида:
(Выбор когда ВТ_Местная.р1= ВТ_Удаленная.р1 тогда истина иначе ложь конец) КАК поле1

(23) В данном случае долгой операцией будет загрузка параметров (т.е. ТЗ) в твой запрос, а не само выполнение запроса.
И нужно проиндексировать реквизиты ВТ_Местная.ИД и  ВТ_Удаленная.ИД.

Попробуй переделать свой алгоритм так, что бы всё можно было получить запросом без подгрузки ТЗ через параметры. Т.е. всё сделать одним запросом.

(24) другому алгоритму не быть - одна из таблиц приходит извне, другая не может быть обработана в запросе.
запросом таблицы обрабатываются, потому что сервер sql сделает это быстрее, чем любой другой алгоритм на "восьмерке".
таблицы большие, поэтому вариант "оптимизировать на мелочах" очень даже приемлем.

(25) > другая не может быть обработана в запросе
Возможно и может. В запросах можно такое накрутить если подумать...
По любому если таблица не приходит извне, значит приходит с сервера. Обработав её без пересылки туда сюда, можно существенно ускорить.

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