при подготовке к эксперту нашел "материал", что "В ИЕРАРХИИ" в виртуальных таблицах - зло. ибо тот запрос который формируется для выполнения условия "В ИЕРАРХИИ" ни разу не оптимальный.
и вроде как правильно сначала получить таблицу элементов из иерархии, а уже потом ее использовать в качестве отбора.

есть запросы

ИЗ
    |    РегистрБухгалтерии.Хозрасчетный.Остатки(&ТекущийПериод, Счет В ИЕРАРХИИ (&Счета), , Организация = &Организация)

и

|ИЗ
    |    РегистрБухгалтерии.Хозрасчетный.Остатки(
    |            &ТекущийПериод,
    |            Счет В
    |                (ВЫБРАТЬ
    |                    ТаблицаСчетов.Счет
    |                ИЗ
    |                    ТаблицаСчетов КАК ТаблицаСчетов),
    |            ,
    |            Организация = &Организация) КАК БУ_Текущий


где таблица счетов получается предварительно:

    "ВЫБРАТЬ
    |    Хозрасчетный.Ссылка КАК Счет
    |ПОМЕСТИТЬ ТаблицаСчетов
    |ИЗ
    |    ПланСчетов.Хозрасчетный КАК Хозрасчетный
    |ГДЕ
    |    Хозрасчетный.Ссылка В ИЕРАРХИИ(&Счета)
    |
    |ИНДЕКСИРОВАТЬ ПО
    |    Счет
    |;


замер производительности показывает однинаковые 30 секунд выполнения (второй на 0,15 сек быстрее).


значит фигня про "в иерархии"?

(0) Относительно регистра бухгалтерии - фигня.

Таблица плана счетов в 99,99% случаев достаточно маленькая.

Если бы речь шла об иерархическом справочнике с приличным количеством элементов, то возможно(!) разница была бы более значительной.

+ к (1) поэксперементируй с условиями на значения субконто, например, Номенклатура или Контрагенты (смотря какой справочник поболе).

(0) а ты попробуй на большем объеме данных (в смысле больше элементов внутри группы) и большей вложенности

(2) (3) возможно вы и правы. т.е. во втором случае получается "правильный запрос" но выхлопа особо не дает, так как данных относительно мало...

(4) Запрос правильный и там и там.

Вопрос только в выигрыше (будет ли он?).
На выполнение запроса для отдельного получения таблицы счетов тоже уходит время и накладные расходы на получение результата этого запроса с последующей передачей этого результата обратно на сервер СУБД в качестве параметра основного запроса.

Если уж идти по такому (второму) пути, то может целесообразнее пакет запросов делать, чтобы не гонять данные туда-сюда между серверами СУБД и 1С.

(4) это же элементарно, Ватсон. Во втором запросе используется кеш от первого запроса.

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

(5) Просветите, пожалуйста, пакетный запрос выполняется не на сервере СУБД, а гоняется туда-сюда по частям?

(7) нет...на сервере

&Счета - это группа счетов-то хоть?

а еще лучше - список групп счетов

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

(Счет, Истина) В
    |                (ВЫБРАТЬ
    |                    ТаблицаСчетов.Счет, Истина
    |                ИЗ
    |                    ТаблицаСчетов КАК ТаблицаСчетов)

(0) Ты - эксперт? Бугага.

(10) список групп счетов и счетов )

(11) да точно, ты уже как то про него говорил, тогда реально сработало ))) попробую применить )

(12) давай. разбей меня в пух и прах своими знаниями.

(12) в какое соединение выльеться в итоге (в иерархии) в виртуальной таблице?

выльется

(11) а в чем прикол?

(11) в данному случае дало прирост 1с секунду ) все равно запросы почти одинакого выполняются...

В некоторых случаях у меня (несмотря на рекомендации 1с) Где и join отрабатывали быстрее, чем условие на виртуальную таблицу. Но это в РН. По Бухии не готов сказать

(17) В скуле получается не in(), а exists(), а он работает шустрее

сейчас тесты.

запрос в иерархии по регистру бухгалтерии - 47сек
запрос в (таблица, с доп полем истина) по регистру бухгалтерии - 46 секунд
запрос без условия по регистру бухгалтерии - 36 секунд

(22) еще сделай тест - 1 запрос - выгрузка счетов в массив, 2 - отбор по параметру-массиву

(23) т.е. в параметр виртуальной таблицы сунуть В (&Массив)?

(20) фигассе... вот это писатели движка )))

хотя при любом раскладе выигрыш будет максимум 10 секунд из 47... так что...

(26) так то четверть...

(19) left join никак не может быстрее отрабатывать, чем exists.

Тьфу, наоборот.

1) Выбрать 1 запросом все счета из иерархии, если так нетерпиться.
2) Обойти кодом счета, получить всевозможные типы субконто.
3) Захерачить в 1 массив счета, в 2 массив - субконто.
4) Запросить остатки.


Другой вопрос, если счетов 100500, тут так делать не надо.