|
|
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
hi all Решил тут проверить произв-сть апдейтов, которые по некоторым причинам надо делать через курсор. Дано: таблица со 100 тыс строками, заполнена в хаотичном порядке. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. gstat -r -t TTT Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Требуется: залочить максимально возможное число из множества мощностью 100 тыс строк, в порядке возрастания ID, используя курсор (т.к. pure-SQL-апдейт не даёт пропускать записи, залоченные конкурентами). Производительность SQL-update оператора (приведена только для сравнения с курсорными вариантами): Код: plaintext 1. 2. 3. 4. Курсорные варианты: 1a. Явный курсор + холостой update с использованием where current of <C> Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Еще были сделаны два варианта для холостого апдейта и select for update with lock, в которых вместо rdb$db_key использовался доступ по ID - они аналогичны 2a & 2b (но проигрывают им). Итог сравнения - см. аттач. Если коротко, то рулят варианты 1a & 1b. Из плана и статистки непонятно, впрочем, за счет чего они обгоняют варианты с доступом через rdb$db_key, ну да ладно. Вопрос, соб-сно, простой: а почему, объявив курсор <C>, нельзя делать что-то типа этого: Код: sql 1. - ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2014, 22:55 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, потому что через rdb$db_key поиск всё же идёт, а при применении where current of мы уже находимся на нужной записи. Читай http://www.ibase.ru/devinfo/dataaccesspaths.htm#chapter113 и http://www.ibase.ru/devinfo/dataaccesspaths.htm#chapter13 и сравни ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2014, 23:52 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Дык я знаю, что при применении where current of мы уже находимся - ну так и что тогда мешает залочить эту "текущую" запись не холостым апдейтом, а "как-то по-другому" ? (но тут лишь одно "другое" средство: select for update with lock...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 00:13 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Таблоид> - ну так и что тогда мешает А что мешает? Таблоид> но тут лишь одно "другое" средство: select for update with lock...) И какая же между ними будет разница? Сэкономленный оператор что ли? :) P.S. Способов, кстати, больше одного и даже больше двух, но нормальный всего один (with lock). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 00:29 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамТаблоид> но тут лишь одно "другое" средство: select for update with lock...) И какая же между ними будет разница? Сэкономленный оператор что ли? :)Глянь в аттач, сравни 2а и 2b: в первом 200 тыс IR'ов + 100 тыс Update'ов, во втором - только 200 тыс IR'ов. Теперь смотрим также на пару 1a vs 1b: в обоих по 100 тыс IR'ов + 100 тыс Update'ов. Я хочу понять, какая будет скорость, если делать что-то типа: Код: sql 1. -тут ведь будет только 100 тыс IR'ов, которые возникли при работе самого курсора, но должно быть 0 (ноль) update'ов. Гаджимурадов РустамP.S. Способов, кстати, больше одного и даже больше двух, но нормальный всего один (with lock).Ткни, плз, в эти самые "ненормальные больше двух". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 01:10 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Таблоид> Я хочу понять, какая будет скорость А зачем ? Практический пример привести придумать можешь или какдемический интерес, как обычно? И кто/что мешает проверить, кстати? Что не получается? > Ткни, плз, в эти самые "ненормальные больше двух". Да мало ли какие извращения можно придумать, типа селекта из процедуры с апдейтом и т.п. Есть кошерный дедовский способ, есть его более кошерная реализация с With Lock-ом - все остальное не лучше и от лукавого. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 01:31 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
> какдемический интерес, как обычно? Оговорка по Фрейду, аднака. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 01:32 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Таблоид- ну так и что тогда мешает залочить эту "текущую" запись не холостым апдейтом, а "как-то по-другому" ? (но тут лишь одно "другое" средство: select for update with lock...) что мешает залочить их в верхнем селекте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 09:08 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисТаблоид- ну так и что тогда мешает залочить эту "текущую" запись не холостым апдейтом, а "как-то по-другому" ? (но тут лишь одно "другое" средство: select for update with lock...)что мешает залочить их в верхнем селекте?хм... надо будет проверить, что там будет, когда часть записей заняты конкурентами. ГРПрактический пример привести придумать можешь или какдемический интерес, как обычно?N produсers -> M consumers, потребители должны обработать одни и те же записи в порядке FIFO. Лок-конфликты неизбежны. Но логика допускает, что если запись сейчас занята, то можно перейти для обработки к следующей. Не знаю, практический это пример для тебя или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 09:27 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидИз плана и статистки непонятно, впрочем, за счет чего они обгоняют варианты с доступом через rdb$db_key 100000 IRs vs 200000 IRs Таблоиддолжно быть 0 (ноль) update'ов не верь глазам своим (с) WITH LOCK просто не показывается в статистике. А на самом деле там есть точно такие же апдейты, как и при холостых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 10:45 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
dimitrне верь глазам своим (с) WITH LOCK просто не показывается в статистике. А на самом деле там есть точно такие же апдейты, как и при холостых.а это можно подправить, чтобы показывались ? или уже "не в этой жизни" (С) - ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 12:57 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, в 3.0 будет такая статистика, но не буду обещать что ее выведет наружу isql... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 13:50 |
|
||
|
cursors benchmark: почему нельзя делать select for update where current of <C> ?
|
|||
|---|---|---|---|
|
#18+
dimitrв 3.0 будет такая статистика, но не буду обещать что ее выведет наружу isql...Это не страшно. Статистика isql - она ведь для доверчивых только. Трейс наше всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2014, 13:56 |
|
||
|
|

start [/forum/topic.php?fid=40&gotonew=1&tid=1563424]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
169ms |
get topic data: |
10ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 464ms |

| 0 / 0 |
