|
|
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. trace : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Оевидно, что при вставке каждой строки в TDETL движок проверял наличие родительской записи в TMAIN. В статистике на это намёков не видно (про вызовы "скрытого" check_NN триггера я уж не говорю). Это так и должно быть ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 16:35 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, да. Тебе же 100 раз было сказано что в статистике отображаются индексированные чтения (чтения по индексу), а не чтение самого индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 16:48 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, как раз check-триггер и проверяет наличие записи в родителе. А статистику его вызова ты не видишь, ибо он не относится к твоему стейтменту (как и любой другой триггер или ХП). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 16:48 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrкак раз check-триггер и проверяет наличие записи в родителе. А статистику его вызова ты не видишь, ибо он не относится к твоему стейтменту (как и любой другой триггер или ХП).Ну так что следует сделать (запустить), чтобы деятельность этого check-триггера вылезла в статистику ? И вообще как-то туманно звучит: "не относится к твоему стейтменту". Он (этот check-триггер) работает ведь именно когда я дёргаю дочернюю таблицу, как и было показано выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 17:27 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисда. Тебе же 100 раз было сказано что в статистике отображаются индексированные чтения (чтения по индексу), а не чтение самого индекса.Ты утверждаешь, что "чтений по индексу" таблицы TMAIN тут не было ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 17:29 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, может и было. Но как сказал ДЕ оно относится к другому статменту. Вот когда ты создаёшь триггер before/after insert статистика по действиям внутри триггера будет относится к триггеру, а не к оператору insert. Так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 17:37 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денискак сказал ДЕ оно относится к другому статменту .К какому именно "другому" ?? Я ввожу ОДИН стейтмент! Симонов ДенисВот когда ты создаёшь триггер before/after insert статистика по действиям внутри триггера будет относится к триггеру, а не к оператору insert. Так?Если я выкину FK и добавлю триггер TDETL_BIU, эмулирующий FK-проверку: Код: 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. Код: 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. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. Напоминает "тут играем, а тут рыбу заворачивали". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 20:23 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
сейчас перепроверил - операции триггеров должны включаться в статистику "родителя". Надо проверять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 20:30 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидА стейтмент, прописанный в явно созданном TDETL_BIU - уже относится. извиняюсь был не прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 20:32 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrсейчас перепроверил - операции триггеров должны включаться в статистику "родителя". Надо проверять.А нельзя ли фикс (если он будет) сделать прежде всего для 3.0 (где есть mon$-новшества) и прислать мну в мыльце в виде патчика ? А то ну очень надо - ты же знаешь причину этой "пурги"! :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 20:40 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
фикса не будет. Я зарапортовался, никакого check-триггера без каскада есс-но нет. FK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают (и не должны). Т.е. Денис выше все правильно написал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 21:00 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrFK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают ( и не должны ).Как именно проверяется FK, ведь в родит. таблицу надо слазить или нет ? И если обращения к ней таки есть (да еще и для каждой из 100500 млн добавляемых в деталь строк), то почему они не должны показываться ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 21:07 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидdimitrFK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают ( и не должны ).Как именно проверяется FK, ведь в родит. таблицу надо слазить или нет ? И если обращения к ней таки есть (да еще и для каждой из 100500 млн добавляемых в деталь строк), то почему они не должны показываться ?А, стоп. Пардон, я понял: ты говоришь о том, что в родит. ТАБЛИЦУ вообще нет обращений, есть только ходьба в её ИНДЕКС. Ну так это же IR , нет разве ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 21:08 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
значит, так. Выборки из таблицы нет. Поиск в индексе есть. Обращение к таблице тоже есть, но довольно специфическое. Технически наверное его можно назвать индексным, хотя формально оно не относится ни к seq_reads ни к idx_reads. Я пока не знаю, как это будет правильнее показать в статистике. Буду думать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 21:25 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrВыборки из таблицы нет. Поиск в индексе есть. Обращение к таблице тоже есть, но довольно специфическое.ИМХО, оно какое-то уж слишком "спецфицьское". Потому что заставляет ФБ делать больше фетчей при каскаде, чем при его эмуляции (каждая строка детали требует там на 2 фетча больше - что при вставках в деталь, что при удалении в родителе. А при удалении, кстати, идёт проигрыш каскада не только по фетчам, но и по времени. DDL для каскада: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: 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. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. Делаем insert 1 млн строк в деталь таблицу схемы "каскад": Код: plaintext 1. 2. 1. Для схемы "каскад" : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 2. Для схемы "эмулятор каскада" : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Теперь commit + удаляем родительскую строку, что повлечёт грохание 1 млн строк в детали в каждой схеме. Trace: 1. Для схемы "каскад" : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 2. Для схемы "эмулятор каскада" : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. PS. LI-T3.0.0.31309 (впрочем, и на всех предыдущих билдах 3.0, а также на всех 2.5 - то же самое) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 22:25 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидПотому что заставляет ФБ делать больше фетчей при каскаде, чем при его эмуляции Каскадные операции тут ни при чём. Это расходы на поддержание ссылочной целостности, которую твоя эмуляция не обеспечивает. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 22:40 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЭто расходы на поддержание ссылочной целостности, которую твоя эмуляция не обеспечивает."Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 22:45 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
Таблоид"Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ? то самое "специфическое" чтение записи из таблицы, один фетч на PP и один на DP - все как обычно. Требуется чтобы сравнить поля связи мастера со слейвом (ключ индекса может "врать", ибо априори неточен). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 22:52 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоид"Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?то самое "специфическое" чтение записи из таблицы, один фетч на PP и один на DP - все как обычно. Требуется чтобы сравнить поля связи мастера со слейвом (ключ индекса может "врать", ибо априори неточен).А зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ? Разве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 22:59 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидА зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ? а откуда сервер знает, что следующая деталь будет ссылаться на того же мастера? В общем случае это не так. Кроме того, записи мастера и так буферизируются страничным кешем. ТаблоидРазве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ? кто "она"? Какое-такое "блокирование"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 23:05 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидА зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ?а откуда сервер знает, что следующая деталь будет ссылаться на того же мастера? В общем случае это не так. Кроме того, записи мастера и так буферизируются страничным кешем.Вставка в деталь-таблицу записей с числом dictinct parent-ключей, равным числу dictinct ключей в мастере - это самый худший случай. Это вообще похоже на связь 1-1. В бол-ве случаев в деталь-таблицу идут вставки, в select count(distinct parent_id) << select count(master.id). Не понимаю, почему бы не запоминать "где-то там в памяти" значения из master-таблицы, дабы вообще не лазить за ними на следующих повторах (в рамках этого же стейтмента). dimitrТаблоидРазве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ? кто "она"? Какое-такое "блокирование"?Запись master-таблицы. Она блокируется до тех пор, пока идёт вставка в detail. Например, при добавлении в вышеприведенном скрипте в таблицу tdetl_casc 1 млн строк, второе окно, пытающееся удалить master-строку, получает по лбу: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2014, 23:53 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЭто вообще похоже на связь 1-1. вполне легальная связь, которой пользуется куча народу ТаблоидВ бол-ве случаев в деталь-таблицу идут вставки, в select count(distinct parent_id) << select count(master.id). кто сказал, что они идут в порядке возрастания/убывания ключей мастера? И что вообще будет более одной вставки в деталь? ТаблоидНе понимаю, почему бы не запоминать "где-то там в памяти" значения из master-таблицы, дабы вообще не лазить за ними на следующих повторах (в рамках этого же стейтмента). "где-то там в памяти" = в страничном кеше. Хватит уже натягивать сову на глобус. ТаблоидЗапись master-таблицы. Она блокируется до тех пор, пока идёт вставка в detail. нет никакого блокирования ТаблоидНапример, при добавлении в вышеприведенном скрипте в таблицу tdetl_casc 1 млн строк, второе окно, пытающееся удалить master-строку, получает по лбу ибо при удалении мастера проверяется ссылочная целостность (наличие строк-деталей) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 00:04 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
А, и еще тут вылезло, в схеме "каскады". Исходные данные: в таблице tmain_casc - одна строка, в подчинённой ей tdetl_casc - ноль: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Далее делаю так: session #1 (в трейсе ниже - ATT_720). Запускаю вот этот скрипт (file = 'ins'): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. session #2 (в трейсе ниже - ATT_722). Запускаю в ней примерно через 5-7 сек вот это: Код: plaintext И получаю... обломы в ОБЕИХ сессиях! Вот трейс: Код: 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. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 00:11 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидВ бол-ве случаев в деталь-таблицу идут вставки, в select count(distinct parent_id) << select count(master.id).кто сказал, что они идут в порядке возрастания/убывания ключей мастера? И что вообще будет более одной вставки в деталь?Да пусть хоть в порядке винегрета, какая разница ? Пусть последовательность вставки в detail такая: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Тут три раза повторяется значение "444555". Движок сейчас три раза ходит в индекс master'a с поиском "444555" и, насколько я понимаю, таки шарит еще и в самом master'e, в его PP + DP, ибо:dimitrключ индекса может "врать", ибо априори неточенПочему нельзя, один раз сходив за ключиком "444555", добавить его куда-нить в структуру-аналог TreeSet'а, что бы прежде чем ходить за ним в следующие разы, проверить этот TreeSet ? И при наличии там этого ключа - сказать себе: "да, такой ключ уже БЫЛ прочитан из master'a, и его не надо заново фетчить!" dimitrТаблоидНе понимаю, почему бы не запоминать "где-то там в памяти" значения из master-таблицы, дабы вообще не лазить за ними на следующих повторах (в рамках этого же стейтмента)."где-то там в памяти" = в страничном кеше.Что будет сохранено в страничном кеше - запись master'a ? Ну так от повторных фетчей (в индексе + PP + DP) это не избавляет! dimitrТаблоидЗапись master-таблицы. Она блокируется до тех пор, пока идёт вставка в detail.нет никакого блокированияЕсть "что-то", не позволяющее мну добавить в деталь новые строки, пока в соседнем окне идёт delete from tmain_casc where id = 1. Если это не блокирование master-записи, то что тогда ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 00:24 |
|
||
|
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидТут три раза повторяется значение "444555". а если это будет три повторения из 100500 записей? Создание FK на табличке-миллиарднике. Давай-ка закешируй мастер. ТаблоидПочему нельзя, один раз сходив за ключиком "444555", добавить его куда-нить в структуру-аналог TreeSet'а, что бы прежде чем ходить за ним в следующие разы, проверить этот TreeSet ? И при наличии там этого ключа - сказать себе: "да, такой ключ уже БЫЛ прочитан из master'a, и его не надо заново фетчить!" предлагаю проследовать в сад ТаблоидЧто будет сохранено в страничном кеше - запись master'a ? Ну так от повторных фетчей (в индексе + PP + DP) это не избавляет! похер. Что ты так привязался к этим фетчам? Они тебе жмут? ТаблоидЕсть "что-то", не позволяющее мну добавить в деталь новые строки, пока в соседнем окне идёт delete from tmain_casc where id = 1. Если это не блокирование master-записи, то что тогда ? оно так и говорит - "не позволю!"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 00:34 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38733722&tid=1563367]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
193ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 486ms |

| 0 / 0 |
