|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
Привет всем. Оправдано ли для параметров в хранимой процедуре применение MERGE вместо UPDATE OR INSERT? Ну, что-то типа такого: Код: sql 1. 2. 3. 4. 5. 6. 7.
В MERGE в ветке WHEN MATCHED THEN можно исключить холостой апдейт ключевых полей. Что-то еще? С уважением, Polesov. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 11:09 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
Polesov, ключевые поля не надо апдейтить вовсе. А вот холостой апдейт неключевых полей можно исключить с помощью дополнительных условий в предложении WHEN MATCHED THEN, но только начиная с Firebird 3.0 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
можно пойти дальше и сделать несколько веток when matched ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 11:55 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
Симонов Денисключевые поля не надо апдейтить вовсе Я имел ввиду апдейт ключевых полей при использовании UPDATE OR INSERT ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 12:13 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
PolesovЯ имел ввиду апдейт ключевых полей при использовании UPDATE OR INSERTА где там апдейт ключевых полей ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 12:41 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
PolesovОправдано ли для параметров в хранимой процедуре применение MERGE вместо UPDATE OR INSERT? Нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 12:58 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
hvladА где там апдейт ключевых полей ? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Правильно ли я понимаю, что при использовании UPDATE OR INSERT в случае выполнения условия MATCHING апдейт поля KEY_FIELD производиться не будет? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 12:59 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
PolesovПравильно ли я понимаю, что при использовании UPDATE OR INSERT в случае выполнения условия MATCHING апдейт поля KEY_FIELD производиться не будет? Атебенепох? Новая версия записи всё равно создаётся со всеми полями. Дельта-версия - только из различий байт, она даже на поля не делит. В чём твой интерес? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 13:07 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
PolesovПравильно ли я понимаю, что при использовании UPDATE OR INSERT в случае выполнения условия MATCHING апдейт поля KEY_FIELD производиться не будет?По идее- не будет, но проверить не помешает. С другой стороны - на что это влияет ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 13:10 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovВ чём твой интерес? Интерес - оптимизация по скорости. Насколько я помню, апдейт ключевых полей вызывает пересчет индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 13:14 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
Polesov, или холостой апдейт ключевого поля не вызывает пересчет индекса? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 13:15 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
Polesov, если поле не меняется, то индекс тоже не меняется. И ключ тут пофигу. Это не PG :) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 13:19 |
|
Вопрос по MERGE
|
|||
---|---|---|---|
#18+
В общем, седлал небольшой тест: Код: sql 1. 2. 3. 4. 5.
В таблицу залил 1 млн записей. Далее 1 млн раз апдейтил одну и ту же запись: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Execute time = 6s 16ms Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Execute time = 5s 437ms Получается, MERGE несколько медленее, чем UPDATE OR INSERT P.S. Все манипуляции производил в IBE ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2017, 14:16 |
|
|
start [/forum/topic.php?fid=40&fpage=49&tid=1561742]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 283ms |
total: | 423ms |
0 / 0 |