Допустим, я хочу сделать полное соединение какой-нибудь таблицы с табличной частью конкретного документа. Имеет ли смысл помешать сначала табчасть во временную таблицу? Ведь отбор происходит после соединения.

(0) Поразмышляв, что-то не придумал как лучше... Делай как удобнее...

В пользу помещения во временную таблицу вроде есть аргумент) А что с запросом без ВТ?

http://kb.1c.ru/articleView.jsp?id=44

(3) Не увидел ничего, относящегося с теме.. Куда смотреть?

В данном случае смысла нет делать ВТ.
Да и соединение нужно скорее всего Внутреннее, а не полное. )

(5) И вообще мне нужно предопределенное значение плана видов расчета)
Почему нет смысла делать ВТ? По-моему, как раз наоборот. Да и по логике вешей

(6) Если ты после (0) далее будешь использовать или соединять результат с чем либо тогда есть.
Ну а если с фанатизмом то можно взять таб1 - загнать во временную. Взять таб2 - тоже загнать во временную. Ну а потом соединить временную 1 и 2 после чего удалить временные
(шутка).

вот тут почитай http://kb.mista.ru/article.php?id=628

Или вот https://www.google.ru/#newwindow=1&q=временные%20таблицы%201с

Думаю, для полного соединения имеет смысл ВТ, потому что вариант с условием соединения и ГДЕ Т1.Чтото is null или Т2.Ссылка = &Док как-то не выглядит оптимальным.

(8) И что я там должен был увидеть?
В таблице табличных частей всех документов может быть спокойно 1млн+ записей. В нужном документе 10. Если верить расчетам, то при помещении будет в 100000 меньше записей.

(0) Полное соединение это вид соединения двух таблиц или ты про Объединение (ОБЪЕДИНИТЬ ВСЕ) двух таблиц говоришь?
Индекс полезен именно при соединении. А вот при объединении польза вряд ли будет. Для объединения больших таблиц (говорю про MSSQL) чаще всего используется следующая последовательность алгоритмов:

Concatenation - http://msdn.microsoft.com/ru-ru/library/ms187919(v=sql.105).aspx
затем Hash Match - http://msdn.microsoft.com/ru-ru/library/ms189582(v=sql.105).aspx

т.е. для достижения максимальной скорости при объединении используются hash таблицы а не индексы.
Например. Имеем такой запрос:
http://f-lite.ru/lfp/s018.radikal.ru/i502/1403/ab/b2f59eb98999.png/htm

Как я понял ситуация очень похожа на вашу – Объединяются две достаточно большие таблицы, одна из них остатки регистра, другая ТЧ документов.

План его выполнения выглядит таким образом:
http://s52.radikal.ru/i137/1403/be/9859b392d1fd.png

План состоит из двух ветвей, которые в конечном итоге соединяются. В «нижней» ветке, извлекаются данные из регистра, а в верхней соответственно из ТЧ документов «Реализация товаров и услуг». Затем эти данные объединяются в одну таблицу. Вы видите, что соединяются ветки в операторе Concatenation. А после него сразу идет Hash Match, этот оператор группирует входные данные (суммирует значение колонки «Сумма Накладных» для записей с одинаковой «Точкой доставки» и «Накладной»).

(0) Помимо теории есть смысл сделать оба варианта и посмотреть профайлером планы и их стоимость. Сравнить показатели событий RPCCompleted и SQLBatchcomleted в частности CPU, Reads, Writes

Как правило, соединение нужно делать с табличной частью ОДНОГО конкретного документа, поэтому сначала настоятельно рекомендуется выбрать эту ТЧ во временную таблицу по условию ГДЕ Ссылка = &Ссылка, а потом уже применять соединение к временной таблице. А если вы сразу присоедините таблицу регистра к табличной части, а потом уже отберете по ссылке в условии "ГДЕ" - это сами понимаете ггг...

(14) бред

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

(16) для оптимизатора MS SQL часто нет значения где в тексте запроса указаны условия (при одинаковой конечной выборке)

(14) Вот-вот. Я преследую ту же логику.
И странно, что все молчат. Вроде чуть ли не самый простой вопрос из серии оптимизации..

(0) Полное соединение вообще тяжелая штука. Лучше его не делать, если есть возможность.

(19) полное не очень тяжелое
тяжелое декартово произведение