Добрый день! У клиента база УПП релиз 1.3.10.1.
Возник вопрос в производительности запроса в 8.2 с вкл. и выкл. режимом совместимости с 8.1. Когда режим совместимости ВКЛЮЧЕН, запрос выполняется в среднем в 400 раз быстрее, нежели когда режим ВЫКЛЮЧЕН!!!

Собственно запрос:

ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
  Основания.Основание
ИЗ
  Документ.ПоступлениеТоваровУслуг.Основания КАК Основания
ГДЕ
  Основания.Ссылка = &Ссылка
  И Основания.Основание В
    (ВЫБРАТЬ
       Основания.Основание
     ИЗ
   Документ.ПоступлениеТоваровУслуг.Основания КАК Основания
     ГДЕ
   Основания.Ссылка.Проведен
   И Основания.Основание <> НЕОПРЕДЕЛЕНО
   И НЕ (Основания.Основание В (&ПустаяСсылка))
   И Основания.Ссылка <> &Ссылка)

Запрос проверяет, указано ли какое-нибудь из оснований в текущем документе ПТиУ в других документах ПТиУ.
В качестве параметра &Ссылка передается ссылка на текущий документ ПТиУ.
Реквизит "Основание" ТЧ "Основания" имеет составной тип данных.
В качестве параметра &ПустаяСсылка передается массив, состоящий из ссылки на новый НЕ типовой документ.

Почему так происходит? Вроде без режима совместимости конфа должна быстрее работать, а тут получается наоборот? :(

Режим совместимости не оказывает никакого влияния на скорость выполнения запроса. Скорее всего замер производился не корректно, или при замере влияние оказывал кэш системы.

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

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

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

потом сравниваете полученные два времени.

(1) Кстати, а контроль доступа на уровне полей не может оказывать влияния?

(1) Может ради интереса трейсы посмотришь в обоих режимах, перед тем как сказки-то рассказывать?

По сути, твое высказывание можно перефразировать так:
"Текст запроса и структура таблиц не оказывают никакого влияния на скорость выполнения запроса"....

(4) Разве режим совместимости меняет текст запроса и структуру таблиц?

И Основания.Основание <> НЕОПРЕДЕЛЕНО
   И НЕ (Основания.Основание В (&ПустаяСсылка))


На всякий случай?

А, не, ошибся

Это только у меня текст запроса вызывает тупую, тяжелую злость?

(8) это предотпускное

а в таком запросе разница есть:


Выбрать
 Таблица.ДокОснование,
 Количество(Таблица.Ссылка) КАК КоличествоСсылок,
Поместить НеправильныеОснования
Из
 Таблица как Таблица
Сгруппировать по
 Таблица.ДокОснование
Имеющие
 Количество(Таблица.Ссылка) <> 1
Индексировать по
 ДокОснование
;

Выбрать
 Таблица.Ссылка,
 НеправильныеОснования.КоличествоСсылок
Из
 Таблица как Таблица
 Внутреннее соедиение НеправильныеОснования
   ПО Таблица.ДокОснование = НеправильныеОснования.ДокОснование

(8) да. у меня вызвал улыбку.

Да, запрос написан не очень красиво - но вопрос-то не в этом!
Попробую поперезагружаться и сравнить замеры

(12) не трать время. лучше запрос перепиши.

(5) Вроде, контроль прав доступа на уровне полей появился только в 8.2. А это может сильно менять структуру запроса и снижать скорость исполнения.

"Вроде без режима совместимости конфа должна быстрее работать"
странно, вроде говорили совсем обратное...

+(15) упс... "обчитался" :)

Вообще, если судить по субъективным ощущениям, то 8.2 немного тормознее, чем 8.1. Но это чисто на уровне субъективных ощущений. Вот когда 8.1 появилась, то по ощущениям она была быстрее 8.0.

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

(18) это не "после одного из релизов", это так и есть. лучше внутреннее соединение юзать, если можно

(19) возможно Вы правы.
Но не всегда возможно использовать внутреннее соединение

(20) Естественно. Надо нормализовать структуру хранения данных

(4) Не надо меня перефразировать.

Текст запроса не менялся.

Как поменялись таблицы при смене режима совместимости (те которые в запросе указаны)?

Скорость выполнения не изменится из-за изменения режима совместимости.

Только что проверил на бухии.

То что в (0) запрос "слегка не оптимальный" это другой вопрос.

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

(0) а если под полными правами и убрать РАЗРЕШЕННЫЕ у запроса, то сравнить время?

(24) Насколько я помню, запрос с "РАЗРЕШЕННЫЕ" исполняется быстрее.

(25)там просто записей меньше в результате

(21) Будто после нормализации эта возможность будет всегда.
(22) Скорость может и не меняется... а интерпретируется запрос одинаково?

(27) А вопрос разве в этом был?  Для приведенного текста запроса одинаково.

(28) Ну так судя по всему при изменении совместимости меняются правила по которым работает интерпретатор. Отсюда и изменение в скорости работы

(29) Работа интерпретатора не зависит от режима совместимости. Исключение: таблицы констант.

Вообщем переписал текст запроса. Теперь разница во времени стремится к нулю :)
Всем спасибо за ответы!

P.S. Удаление ключевого слова "РАЗРЕШЕННЫЕ" ничего не изменило

Файловая?????

(31) на (10)?

(32) да
(33) нет, сделал совсем просто:

ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
  Основания.Основание
ИЗ
  Документ.ПоступлениеТоваровУслуг.Основания КАК Основания
ГДЕ
  Основания.Ссылка.Проведен
  И Основания.Основание <> НЕОПРЕДЕЛЕНО
  И (НЕ Основания.Основание В (&ПустаяСсылка))
  И Основания.Ссылка <> &Ссылка
  И Основания.Основание В (&МассивОснований)

В параметр &МассивОснований передаю массив ссылок-оснований из текущего документа

(22) Я так понимаю лень трейс самому снять, лучше на форуме пофлудить ? ;)

Мне не сложно, вот "неизмененные" тексты запросов.

Режим совместимости: Версия 8.2.13

exec sp_executesql N'SELECT DISTINCT
T1._Fld25816_TYPE,
T1._Fld25816_RTRef,
T1._Fld25816_RRRef
FROM _Document405_VT25813 T1 WITH(NOLOCK)
WHERE (T1._Document405_IDRRef = P1) AND EXISTS(SELECT
1
FROM _Document405_VT25813 T2 WITH(NOLOCK)
LEFT OUTER JOIN _Document405 T3 WITH(NOLOCK)
ON T2._Document405_IDRRef = T3._IDRRef
WHERE (T3._Posted = @P2 AND (T2._Fld25816_TYPE <> @P3) AND (NOT (((T2._Fld25816_TYPE = @P4 AND T2._Fld25816_RTRef = @P5 AND T2._Fld25816_RRRef IN (@P6))))) AND (T2._Document405_IDRRef <> P1)) AND (T1._Fld25816_TYPE = T2._Fld25816_TYPE
AND T1._Fld25816_RTRef = T2._Fld25816_RTRef AND T1._Fld25816_RRRef = T2._Fld25816_RRRef))', N'P1 varbinary(16),@P2 varbinary(1),@P3 varbinary(1),@P4 varbinary(1),@P5 varbinary(4),@P6 varbinary(16)', 0x8D3250505450303011D8EA23BEA97295,
0x01, 0x01, 0x08, 0x00000195, 0x00000000000000000000000000000000

Режим совместимости: Версия 8.1

exec sp_executesql N'SELECT DISTINCT
_Document405_VT25813_Q_000_T_001._Fld25816_TYPE AS f_1,
_Document405_VT25813_Q_000_T_001._Fld25816_RTRef AS f_2,
_Document405_VT25813_Q_000_T_001._Fld25816_RRRef AS f_3
FROM
_Document405_VT25813 _Document405_VT25813_Q_000_T_001 WITH(NOLOCK)
WHERE
_Document405_VT25813_Q_000_T_001._Document405_IDRRef = P1 AND EXISTS(
SELECT
_Document405_VT25813_Q_001_T_001._Fld25816_TYPE AS _Q_001_F_000_TYPE,
_Document405_VT25813_Q_001_T_001._Fld25816_RTRef AS _Q_001_F_000_RTRef,
_Document405_VT25813_Q_001_T_001._Fld25816_RRRef AS _Q_001_F_000_RRRef
FROM
_Document405_VT25813 _Document405_VT25813_Q_001_T_001 WITH(NOLOCK)
LEFT OUTER JOIN _Document405 _Document405_raevjiwz WITH(NOLOCK)
ON _Document405_VT25813_Q_001_T_001._Document405_IDRRef = _Document405_raevjiwz._IDRRef
WHERE
_Document405_raevjiwz._Posted = @P2 AND _Document405_VT25813_Q_001_T_001._Fld25816_TYPE <> @P3 AND NOT (_Document405_VT25813_Q_001_T_001._Fld25816_TYPE = @P4 AND _Document405_VT25813_Q_001_T_001._Fld25816_RTRef = @P5 AND
_Document405_VT25813_Q_001_T_001._Fld25816_RRRef IN (@P6)) AND _Document405_VT25813_Q_001_T_001._Document405_IDRRef <> P1 AND _Document405_VT25813_Q_000_T_001._Fld25816_TYPE = _Document405_VT25813_Q_001_T_001._Fld25816_TYPE AND
_Document405_VT25813_Q_000_T_001._Fld25816_RTRef = _Document405_VT25813_Q_001_T_001._Fld25816_RTRef AND _Document405_VT25813_Q_000_T_001._Fld25816_RRRef = _Document405_VT25813_Q_001_T_001._Fld25816_RRRef)', N'P1 varbinary(16),@P2
varbinary(1),@P3 varbinary(1),@P4 varbinary(1),@P5 varbinary(4),@P6 varbinary(16)', 0x8D3250505450303011D8EA23BEA97295, 0x01, 0x01, 0x08, 0x00000195, 0x00000000000000000000000000000000

В режиме "Не использовать" (= 8.2.14) и структура таблицы изменится, правда незначительно.

(35) Как таблицы изменятся?
Почему запрос к куче таблиц делает обращение? Про связанные данные небыло речи У ТС.
Если я в регистре сделаю поле составного типа и буду от туда данные получать, то естественно при разных платформах трассировка будет хрен знает какой.

(36)
>Как таблицы изменятся?
Если правда интересно можно взять самому и посмотреть.
>Про связанные данные небыло речи У ТС.
В (0) косвенно спрашивал может ли производительность зависеть от режима совместимости.
Некий большой специалист в (1) написал что ни как не может - ведь текст запроса-то одинаковый.
Я в (35) привел результаты трансляции запроса из (0) в TSQL при разных режимах совместимости.
О каких связанных данных идет речь?

Дальше уже совсем какой-то поток мысли пошел, поэтому прокомментирую только:
>...при разных платформах трассировка...
Платформа, конфигурация и запрос с которых получены трейсы в (35) не менялись. Менялся только режим совместимости (это такое свойство корня конфигурации).

(37) ну и запросы то по сути одинаковые, что с совместимостью, что без.

(30) если смотреть в (35) все таки зависит?
(38) в каком месте, простите, они одинаковые?