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

INSERT INTO #tt24 WITH(TABLOCK) (_Period, _RecorderTRef, _RecorderRRef, _Fld8417RRef, _Fld8418RRef, _Fld8419RRef, _Fld8420, _Fld8421RRef, _Fld8422RRef, _Fld281) SELECT
T1._Period,
T1._RecorderTRef,
T1._RecorderRRef,
T1._Fld8417RRef,
T1._Fld8418RRef,
T1._Fld8419RRef,
T1._Fld8420,
T1._Fld8421RRef,
T1._Fld8422RRef,
T1._Fld281
FROM dbo._InfoRgSL8427 T1
INNER JOIN dbo._InfoRg8416 T2
ON T2._Fld8417RRef = T1._Fld8417RRef AND T2._Fld8418RRef = T1._Fld8418RRef AND T2._Fld8419RRef = T1._Fld8419RRef AND T2._Fld281 = T1._Fld281
WHERE (((T1._Fld281 = P1)) AND (T2._Fld281 = @P2)) AND (T2._RecorderTRef = 0x0000008D AND T2._RecorderRRef = @P3)


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

Это глюк или хитрый план?
Платформа 8.3.12

(0) обе таблицы огромные?

попробуй сначала отбор по одной, а потом соединение, если это вощможно на стороне 1С

Это явный глюк. Хитрые планы в природе встречаются гораздо реже.

Это вставка во временную таблицу, а не запись в регистр.

Скан таблицы ты сам заказал, не указав в УСЛОВИЯХ СОЕДИНЕНИЯ ограничение на КЛЮЧЕВОЕ для таблицы среза первых (последних) поле period. Условие на регистратор применяется уже к итогам     объединения.

(4) если для таблицы среза не указывать период, то берутся текущие итоги
(0) выкладывай план в sqlplan

(5) В 1С - да. Из ограничения приведенного запроса этого не следует.

(0)ну дык срез-же... там случайно не ресурсы тебе нечисловые нужны?

Хех... Один из параметров запроса оказался зареганным на форуме)

(0) Т.е. индексы не соответствуют описанию тут?
https://its.1c.ru/db/metod8dev#content:1590:hdoc@2db36f1b

Ну, ничего нового.

Если внимательно прочитать заголовок, то можно увидеть

"документ медленно записывает регистр сведений, который ему подчинен и имеет срез итогов. "

В процессе записи регистра, есть этап записи во временную таблицу, это делает платформа. 600 kReads на ровном месте.

(11) Вы уже сообщили куда следует?

как вариант сделать свою таблицу итогов

(12) (13) Я уже прочитал где следует

http://downloads.v8.1c.ru/content//Platform/8_3_13_1644/1cv8upd_8_3_13_1644.htm#199f74c8-0668-11e8-a3f7-0050569f678a

Для регистров сведений реализовано формирование кластерного индекса по измерениям для физических таблиц среза первых и среза последних. Описание структуры индекса (см. здесь).

Отключен контроль уникальности индексов.

Оптимизированы запросы получения данных из таблиц срезов.

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

Источник: http://downloads.v8.1c.ru/content//Platform/8_3_13_1644/1cv8upd_8_3_13_1644.htm#0055064e-0a7f-11e8-a3f7-0050569f678a

Ну как так то, почему это появилось в 8.3.13, на которую мы не перейдем еще долго.

Но у меня есть хитрый план.

(16) Как правильно было замечено в (3): "Это явный глюк. Хитрые планы в природе встречаются гораздо реже."

это из-за суррогатного поля первичного ключа или что-то типа того?

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

А запросу нужны вот эти парни
T1._Period,
T1._RecorderTRef,
T1._RecorderRRef,

которых нет в некласетрном индексе

(0) попробуйте ради интереса в студии inner hash join

Будни экспертов по платформе.

индекс можно ручками добавить, если так нужно

(23) Ох уж эти хитрые планы.

(24) да пожизненно так делали

(16) это нарушение лиц. соглашения

(26) вот ведь проблема

(27) это факт, а проблема или нет - решает каждый сам для себя...

Как-то беспечно 1Сники пока что относятся к нарушению лицензионного соглашения. А ведь с точки зрения ЛС, что платформу крякнуть, что индекс средствами СУБД ляпнуть, это всё едино нарушение ЛС, со всеми вытекающими.

я писал об этой ошибке год назад на форуме разработчиков 1с https://partners.v8.1c.ru/forum/, на что мне был дан ответ что это зарегистрированная ошибка. суть в том что таблицы, в которых хранится срез актуальных итогов ( т.е. при установленном флаге "Хранить итоги срез последних" практически единственная представляет из себя кучу (т.е. не имеет кластеризованного индекса, данные не упорядочены) помимо этого настройка регистра сведений : признак индексировать у измерения также не переносится в эту таблицу.  вариантов несколько:  1) отключить флаг "Хранить итоги срез последних"  2) в запросе указать дату (возможно отличную от текущей хотя бы на секунду) - будет использован подзапрос к основной таблице 3) самостоятельно навешать кластеризованный индекс = )