Нужно ли удалять временные таблицы

я думаю, что нужно соблюдать хороший стиль, и подчищать за собой

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

Если требуется быстродействие и достаточно памяти сервера, то не стоит удалять таблицы, т.к. на это требуется время. Сервер и сам затем подчистит временные таблицы, как писал Kaiden.

Я обычно чищу за собой.
Только не в случае множественных запросов в цикле :-)

А СКУЛ сервер не поджирает память из-за временных табличек, удалится то они удалились, а память была выделена, может зависла аль еще чего... )

В книге знаний Миста: Если временных таблиц много и они висят в памяти не удаленные не очищенные возникает эффект постоянной загруженности сервера 1с предприятие как будто этот процесс выполняет все время какой то тяжелый запрос или обработку что сказывается на производительности системы в целом. Временную таблицу нужно удалять как можно скорее после использования.

http://aitika.ru/otvety/2472-1c-Nemnogo-teorii-Vremennie-tablitsi - здесь больше и четче прописаны нюансы (в том числе и в комментах).
)

Я этой статье с Мисте не особо верю :)
Надо проверять, конечно, но каким образом временные таблицы могут грузить сервер приложений 1С? Еще можно было бы понять, что они бы грузили сервер СУБД...
Хотя для точности нужно проверять, конечно.

За ссылку спасибо, почитаю.

МенеджерВременыхТаблиц и просто в запросе "ПОМЕСТИТЬ Таблица" как они отличаются в этом плане?

мне кажется надо чистить по любому

Была проблема следующего рода: На связке 1С УПП, сервера 1С x64 и PostgreSQL (все это под управлением CentOS)при удалении временных таблиц - платформа 1С падала, вслед за ней падал и весь сервер 1С.

ИМХО, имеет смысл удалять ВТ только в том случае, если используется менеджер временных таблиц, т.к. на время существования менеджера ВТ будут существовать, а следовательно, не нужные ВТ будут также висеть в памяти, а их следовало бы удалить. Вот как-то так)

Удалять всегда, особенно кто еще работает на 8.1, да и на 8.2 не мешает. Очень часто происходит дефрагментация памяти , что приводик к ее учеткам. Пока менеджер 1С (сборщик мусора :)) плохо справляется со своей работой :)

Вопрос об удалении ВТ, кстати, не праздный. Получили однажды на скуле ошибку, когда база tempdb заполнила собой весь раздел на диске! Отсюда вопрос: это проблема некорректно работающей конфигурации/платформы (не удаляются ВТ) или выделения объема под tempdb, т.е. проблема DBA? Для справки: объем диска (целиком отдан под tempdb) был 270Гб...

1) Тут все пишут про временные таблицы. Действительно, это могло вызвать проблему, если допустим сеанс пользователя оборвался (экстренно упал процесс rphost или какие-то другие причины), следовательно платформа не смогла удалить эти временные таблицы и они остались висеть в tempdb. Те, кто пишут про оперативную память, видимо не понимают, что временные таблицы в случае связки с ms sql всегда пишутся в tempdb и лишь потом в случае необходимости помещаются в оперативную память.
По поводу очистки временных таблиц в случае использования менеджера - в 8.1 это обязательно нужно делать, т.к. таблицы хранятся до закрытия последнего соединения; в 8.2 это желательно, но необязательно, т.к. разработчики платформы сделали автоочистку таблиц (но в некоторых экстренных случая, как я описал выше она может не сработать).
2) Кроме временных таблиц причиной может служить неоптимальные запросы (особенно если используются ограничения RLS). В случае, когда запрос достаточно тяжелый его составные части могут создавать отдельные таблицы в кеше, которые будут помещены также в tempdb (можно искать в плане запроса ключевое слово spool).

Чаще всего на практике присутствует комбинация из этих двух факторов. Следовательно, во всем виноваты "программисты" 1С (если не хватает 270Гб для tempdb не поставить кавычки никак не могу) или в редких случаях некорректное поведение платформы 1С. DBA тут не причем, но расхлебывать придется ему (периодически сжимать tempdb или перезапускать сервер).