|
Как добиться partition elimination в запросе?
|
|||
---|---|---|---|
#18+
Коллеги, приветствую! Вот такая проблем: Имеется секционированная таблица, точнее, две секционированные таблицы, в разных схемах. Необходимо перебросить записи из одной таблицы в другую: Код: sql 1. 2. 3. 4. 5. 6.
Таблицы секционированы по полю regstamp и имеют кластерный индекс по ID_ZAP, regstamp, и имеют некластерный индекс по ID_ACT, regstamp (который, соответственно, тоже секционирован). В темповой таблице, соответственно, имеются 2 поля, ID_ACT и regstamp, которые используются как критерий для переноса Код: sql 1.
Но, в актуальном плане запроса я не наблюдаю ничего похожего на partition elimination. Собственно, вопросы: 1. Можно ли этого добиться? 2. Как этого добиться? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 12:49 |
|
Как добиться partition elimination в запросе?
|
|||
---|---|---|---|
#18+
А что в плане наблюдаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 12:52 |
|
Как добиться partition elimination в запросе?
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич, многопоточное сканирование индекса [regstamp], [ID_ACT] и потом кейлукап недостающих полей. Причем при скане Number of Rows read = миллионы, при том, что в секциях должны быть сотни записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:19 |
|
Как добиться partition elimination в запросе?
|
|||
---|---|---|---|
#18+
uaggster Гавриленко Сергей Алексеевич, многопоточное сканирование индекса [regstamp], [ID_ACT] и потом кейлукап недостающих полей. Причем при скане Number of Rows read = миллионы, при том, что в секциях должны быть сотни записей. Ну так откуда SQL Server знает, данные из каких секций брать, если он сканирует [act].[ZAP]. Варианты на вскидку. 1. Сделать forceseek на [act].[ZAP], тогда на каждую запись из #act будет index seek + keylookup 2. Выбрать уникальные значения regstamp из #act, и через cross apply пройтись по каждому из них Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
В зависимости от количества записей и уникальных regstamp в #act то или иное решение может быть быстрее исходного сканирования всей таблицы [act].[ZAP] ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:33 |
|
Как добиться partition elimination в запросе?
|
|||
---|---|---|---|
#18+
msLex Ну так откуда SQL Server знает, данные из каких секций брать, если он сканирует [act].[ZAP]. Не понимаю. [act].[ZAP] - тоже секционирована и тоже порезана на секции. msLex 1. Сделать forceseek на [act].[ZAP], тогда на каждую запись из #act будет index seek + keylookup Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Так план выглядит более адекватно. Но в #act - в пределе десятки тысяч записей, а в [act].[ZAP] - десятки (сотни) миллионов. Попробую, спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 15:23 |
|
Как добиться partition elimination в запросе?
|
|||
---|---|---|---|
#18+
uaggster msLex Ну так откуда SQL Server знает, данные из каких секций брать, если он сканирует [act].[ZAP]. Не понимаю. [act].[ZAP] - тоже секционирована и тоже порезана на секции. Для того, чтобы сделать partition elimination на [act].[ZAP] sql server нужно знать, к каким regstamp нужно будет обращаться. Информация для этого есть только в #act. Для её использования можно 1. Делать partition elimination относительно каждой записи в #act (вариант 1 с forceseek) 2. Собрать все уникальные regstamp из #act и сделать partition elimination по 1 одному разу на каждый их них (вариант с cross apply) 3. Выбрать max min regstamp из #act и добавить фильтр по диапазону a.regstamp between min_regstamp and max_regstamp. Но это вариант будет работать только в случае, если все regstamp из #act лежат в нескольких, подряд идущих секциях. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 15:42 |
|
|
start [/forum/topic.php?fid=46&msg=39979951&tid=1685874]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 129ms |
0 / 0 |