Index hints in X++ again

[trud]

Цитата:

Сообщение от fed

Я все-таки спрошу - сколько у тебя на проце ядер было и сколько памяти? Но вот в ситуации с 32 процессорами, компиляция плана запроса раскидывается на несколько ядер и таких катастрофических результатов не дает.

Ну я 2 случая проверил - 6с и 64ГБ, 24с и 110ГБ. Так и пользователей обычно больше чем 1. Плюс параллельное выполнение отключают всегда, этож OLTP

Цитата:

Сообщение от fed

В первом случае - время запроса составляло 2-5 секунд, во втором - наверное 20-30 миллисекунд. И я не уверен что вот в такой конфигурации, выигрыш forceplaceholders был бы таким уж чрезвычайным. Если у тебя запрос исполняется 5 секунд, трата даже 200-300 миллисекунд на его компиляцию не так уж заметна

Ну в ряде случаев index hint позволит тебе убрать эти 200-300мс(ну и плюс значительно снизить нагрузку), т.е. это один из инструментов. т.е. с forceliterals у тебя будет 200 на компиляцию + 20 на выполнение. 220 это же гораздо хуже чем просто 20 на выполнение

В общем надо проверять кто решится поставить forceliterals в InventSum::findSum и отписаться о результатах

[fed]

Цитата:

Сообщение от trud

Ну я 2 случая проверил - 6с и 64ГБ, 24с и 110ГБ. Так и пользователей обычно больше чем 1. Плюс параллельное выполнение отключают всегда, этож OLTP

Отключенное параллельное исполнение отключает параллельное исполнение одного запроса. Если у меня куча ядер и куча пользователей, то каждое отдельное ядро может параллельно компилировать/исполнять запросы пришедшие от разных пользователей. Просто твой тест несколько вырожденный. Все-таки в реальности пользователей много и у каждого компиляция идет на своем проце. Во вторых - в реальной ситуации пользователи редко шлют такие запросы пачками. При более или менее правильном программировании уйдет всего один запрос с group by. Ну и наконец - я не предлагаю во всех случаях ставить forceliterals. Я предлагаю его ставить только если у тебя сильно неоднородные данные в каких-то таблицах. Просто в ситуации с моим клиентом там index hint тоже не особо помог бы. Потому что в зависимости от типа номеклатуры там либо надо сначала искать по inventDim и потом джойнится к InventSum, либо наоборот - сначала искать по inventSum, а потом джойнится к InventDim.

Вообще идеальным вариантом было бы, если бы Ax мог бы передавать какой-то тэг для SQL, а внутри SQL можно было бы этот тэг матчить с plan guide. Надо будет посмотреть что они в SQL Server 2017 с plan guide и query store сделали. Тогда в зависимости от типа номенклатуры в моем примере, можно было бы разные тэги передавать и в query store как-то их матчить планам запроса.

[Logger]

Цитата:

Сообщение от fed

Ну и наконец - я не предлагаю во всех случаях ставить forceliterals. Я предлагаю его ставить только если у тебя сильно неоднородные данные в каких-то таблицах.

Лучше бы они в дополнение к index hint разрешили бы применять forceliterals к конкретным полям в которых наблюдается неравномерность распределения данных. Вот это была бы польза. Особенно если это можно было бы админам настраивать в SQLStorage табличке. Тогда можно без кастомизаций обходиться и действовало бы везде в системе.

А пока мы можем включать литералы только для dataAreaId и Partition
Дискриминация получается.

[trud]

Цитата:

Сообщение от fed

Вообще идеальным вариантом было бы, если бы Ax мог бы передавать какой-то тэг для SQL, а внутри SQL можно было бы этот тэг матчить с plan guide. Надо будет посмотреть что они в SQL Server 2017 с plan guide и query store сделали. Тогда в зависимости от типа номенклатуры в моем примере, можно было бы разные тэги передавать и в query store как-то их матчить планам запроса.

Ну что-то кстати обещают в SQL2019
https://www.brentozar.com/archive/20...memory-grants/