v8: Запрос в параметрах виртуальной таблицы #649972

Листал книгу и увидел рекомендации использовать по масимуму параметры виртуальной таблицы вместо левых соединений. Рекомендация привела в тупик (никогда так не делал). Провел два эксперимента:    Документ.РасходнаяНакладная.Номенклатура КАК РасходнаяНакладнаяНоменклатура ИЗ    РегистрНакопления.ОстаткиНоменклатуры.Остатки(                    р КАК р)) КАК ОстаткиНоменклатурыОстатки 2. Как всегда сам делал ВЫБРАТЬ    РасходнаяНакладнаяНоменклатура.Номенклатура,    ОстаткиНоменклатурыОстатки.КоличествоОстаток ИЗ Или я не правильно понял рекомендацию (время выполнения запросов вообще не сравнимо-второй выполняется мгновенно), или лучше книжки не листать?

файловая? клиент серверная? что говорит профайлер, если клиент-серверная? есть ли индекс по номенклатуре?

Я знал, что ты придешь.

Результаты разные будут

Почему товарищи всегда вторым выполняют им выгодный запрос?

ну, и это тоже :)

вот бордо шато бельвью - это хорошее вино?

а где запрос в параметрах?

И база скорее всего мелкая.

лично по мне, по результатам измерений 2003 - 2008 годов - почему-о получается, что четные так себе, а нечетные - ничего

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

Наверное ты мне поможешь. Оцени тяжесть беды ПриПолученииДанных.

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

Выбери остатки на недельку раньше, чем текущая дата.

Ну и скажи результат ВЫБРАТЬ    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ТоварыНаСкладахОстатки.Номенклатура) КАК Номенклатура ИЗ    РегистрНакопления.ОстаткиНоменклатуры.Остатки КАК ТоварыНаСкладахОстатки

индекс у регистра

Тебя не смущает, что 1 и 2 немного разные запросы? С разным результатом

Согласен. Сделаю замер заново. Вопрос тогда по другому поставлю. Нужен ли запрос в параметрах чтобы увеличить скорость, при левом соединении. Вроде как выборка для соединения меньше, но параметр с "В (выбрать" тоже не быстрый.

все зависит от того насколько сократится выборка

р КАК р        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиНоменклатуры.Остатки( Теперь на выходе одно и то же. А вот скорость не подтверждает высказывание про необходимость использования параметров виртуальных таблиц в таком виде

был случай - в левой таблице 6 записей, а в правой 13000 - ограничение правой таблицы через параметры, т.е. сведение к 12 записям и результат выполнения в 300 раз быстрее!

Ну чисто теоретически во вторую таблицу при левом соединении передаются ограничения первого. Просто не всегда надо ограничивать только первой таблицей. Иногда есть другие ограничители.

а для чего тут вообще соединение?

чтобы результаты были одинаковые

Правая была подзапросом или ДТ?

виртуальная таблица остатков содержит 14630 записей (в разрезе только по номенклатуре) в документе 10 различных номенклатур

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

у тебя правая таблица сколько записей стала?

Вопрос поставил меня в тупик. Логически такого не должно быть (постоянно используемые таблицы и без индексов). Но я упал под стол - в РН не было индекса... А этой конфе (на которой проводил эксперимент) уже много много лет и люди работают :-)

. Учти что львиную долю времени занимает создание временной таблицы (в tempeh)

эксперименты нужно проводить на типовых демо базах

остатки с фильтром по идее должны содержать 10 строк (вместо 14630) вот я про то же. нужно ли такое ограничение? переиндексировал. теперь сложно сравнивать - одинаково быстро.

Вот если в первом запросе написать ВЫБРАТЬ    ОстаткиНоменклатурыОстатки.Номенклатура,    ОстаткиНоменклатурыОстатки.КоличествоОстаток ИЗ    РегистрНакопления.ОстаткиНоменклатуры.Остатки(            , ГДЕ Ссылка = &Ссылка)) КАК ОстаткиНоменклатурыОстатки То он будет вне конкуренции

[остатки с фильтром по идее должны содержать 10 строк (вместо 14630)] спасибо, поржал это если нет других измерений

именно это и имелось ввиду об использовании запросов в параметрах вирт таблиц

там будет <= 10 строк

не совсем понял, я разве неправильно посчитал? как их может быть больше, когда на них наложено ограничение из документа (10 разных номенклатур)

Оно имеет ввиду, что таблица остатков имеет вид НОменклатура  Склад Остаток Ном1          Ск1     1 Ном1          Ск2     2

результат замера: с запросом в параметрах на 0.01 секунду медленнее. Но боюсь про это говорить не стоит, могла луна светить в это время по другому

именно

Но если ты будешь юзать Остатки, то у тебя автогруппировка работать будет

если не выбирать второе измерение, то оно само свернется

так мы говорим о виртуальной таблице с одним выбранным измерением.

Без скобок разве тоже свернется? Я просто невкурсе :)

где!?

ИЗ    РегистрНакопления.ОстаткиНоменклатуры.Остатки(            ,

ты мало того что сотворил ВТ, так еще и соединение и пытаешься этот зоопарк сравнивать

это выбранное или отфильтрованное!?

понятно но если параметры предварительно во временную таблицу запихивать то это только ухудшает ситуацию

В общем случае не факт. Если ограничение надо использовать во многих местах, то выигрыш от использования ВТ может оказаться выше проигрыша от записи этой ВТ

но сейчас холивар на конкретном примере :)))

Задача: Определить текущие остатки для контроля отрицательных. Иначе как? Я должен сделать левое соединение табличной части документа и остатков. Вопрос изначально в том, нужно ли в виртуальной таблице в параметры ставить дополнительное условие. а сравниваю один и тот же запрос, но с указанием условия в параметрах ВТ и без. Запрос вроде как логически корректный

это да, но нечасто бывает когда ее используют более 1 разв

не понимаю вопроса.

но оценки результатам даешь красноречивые :))))

Ты просто приводишь конкретный пример для общего правила. Если ты делаешь ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Ч.Остатки ПО ...... То в общем случае ограничение на поле, которое учавствует в ПО ставить не надо. А вот если ты сделаешь ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ ИЗ РегистрНакопления.Ч.Остатки ) ПО..... То в эти остатки надо пихать ограничение

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

я и не пихал ограничение при левом соединении. А в книге рекомендуют так делать...

как раз с виртуальными таблицами не совсем так

?

виртуальные таблицы - это на самом деле вложенные запросы, причем достаточно сложные. и к кускам этих вложенных запросов применяются условия в скобках

а зачем там вообще соединение?

+ если оптимизатор сообразит, то прокинет параметры соединения внутрь для отбора. но это чаще не так.

Ну это понятно. Просто у меня ограничение на правую ВТ никогда не давало прироста скорости. В отличии от ограничения на "явный" вложенный запрос. Могу конечно ошибаться

+ т.е. ДТ. Динамическая таблица, чтоб не путать с временной таблицей :)

в запросе без ограничения в параметрах соединение нужно. во втором запросе (ограничение в параметрах) соединение во первых для чистоты эксперимента, а во вторых именно такая реализация в книге заставила задуматься (и она рекомендовалась )

что за книга-то такая!? я таких рекомендаций не встречал

Если резюмировать, то Фрагстер прав в Передача отбора через ЛЕВОЕ СОЕДИНЕНИЕ целиком и полностью на совести оптимизатора. Задание отбора напрямую - гарантия уменьшения правой таблицы. Так что лучше задавай в параметрах :)

Сори в

попробовал. непонятно почему, но он на много медленнее работает чем с временной таблицей. листаю практическое пособие разработчика 8.2 М.Г. Радченко. Глава "оптимизация проведения документа..."

год выпуска и номер издания

+ номер страницы, где такой пример с листингом

акуеть

сорри, но у меня такой фолиант не сохранился

а вопрос остался. зачем это нужно и нужно ли. получается нужно только для перестраховки от возможной недооптимизации

любые плюшки хороши там где они нужны

Левое соединение - зло, оператор "В" тоже зло ))). Использовать надо "Внутреннее соединение" ))

С удовольствием, если логика позволяет