Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
25.06.2004, 19:55
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
ftp://ftp.software.ibm.com/ps/products/db2/fixes/russian/db2winIA32v8/fixpak/FP6_WR21340/APARLIST.html ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.06.2004, 16:15
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
Сейчас я особо отметил для себя в 6-м фикспаке LOCAL PREDICATES NOT PUSHED THROUGH LEFT OUTER JOIN http://www-306.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/aparlib.d2w/display_apar_details?aparno=IY53213 (важно для моих запросов) а также -901 SQLNO_PROP_ANTIJOIN_CARD()DURING QUERY COMPILE http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/aparlib.d2w/display_apar_details?aparno=IY53698 может, они в этой функции что-то еще поправили? Я изобразил небольшой тест с подсчетом телефонных звонков. Некая таблица, 18 миллионов записей и сотня служебных номеров, которые не должны учитываться, и group by по всему этому (в итоге тыща строк). Это "не должны учитываться" может быть записано двумя способами: t1.phone not in (select t2.phone from t2) и not exists (select * from t2 where t1.phone = t2.phone) Стоимость второго запроса (с antijoin) по плану втрое меньше первого, но реально работает во много раз первого (потому что сортирует 18-миллионную таблицу, для чего создает временную таблицу в temporary tablespace). В первом случае оптимизатор считает, что после применения условия у меня останется 88 тысяч строк, во втором случае он считает (именно это должно называться "antijoin cardinality"), что одна строка(!!!). В реальности же минует фильтр более 17 миллионов. Объяснить DB2 при помощи selectivity действительное положение дел мне не удалось. Интересно будет проверить, не получшеет ли от 6-го фикспака, и как с этим запросом будет справляться Stinger. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.06.2004, 18:52
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
table1 has 8088418 rows table2 has 225363 Three queries, each returns 31662 rows. 1 query: select ..... from table1 join...... where ....... and ( uid not in (select uid from table2 where table1.uid=table2.uid) or uid in (select uid from table2 where table1.uid=table2.uid and table1.timestamp>table2.timestamp) ) estimated cost 833090.937500, works 13.729 seconds 2 query: ( uid not in ( <the same> ) or exists (<the same> ) ) estimated cost 833090.937500, works 14.076 seconds 3 query: ( not exists (<the same>) or exists (<the same>) ) estimated cost 1741.127075 (!), works 15.705 seconds "Интересно будет проверить, не получшеет ли от 6-го фикспака, и как с этим запросом будет справляться Stinger." -> the same here. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.06.2004, 13:57
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
Мой скриптец (вчера я данные LOAD'ом грузил, а сейчас слегка переписал) Код: 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. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.06.2004, 14:01
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
Ха-ха, при выключенном автокоммите CURRENT TIMESTAMP ничего не даст ;-). Ладно, через db2batch запросы прогоню. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.06.2004, 14:07
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
Нет, тут что-то не так. Я помню, что когда-то раньше CURRENT TIMESTAMP был константой в транзакции? Или я глючу? Теперь, во всяком случае - константа в SQL-выражении, то есть обкладывать и перемежать выражения VALUES(CURRENT TIMISTAMP) вполне можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.06.2004, 14:35
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
Потрясающе. 1 108.119 Not Collected 1000 1 2 85.216 Not Collected 1000 1 3 77.765 Not Collected 1000 1 4 60.289 Not Collected 1000 1 Дома у меня not exists безнадежно проигрывал, а на местном сервере выигрывает. Попробовать удесятерить количество данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.06.2004, 14:43
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
И примерное число строк в плане правильное. Чудеса, да и только. Видимо, дело в данных. Буду разбираться. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
01.07.2004, 09:37
|
|||
---|---|---|---|
|
|||
Выпущен DB2 8.1.6 (FixPack 6) |
|||
#18+
На разных данных (примерно одинакового объема) разное поведение. Но и там, и там они сгенерированы при помощи генератора случайных чисел с равномерным распределением. Интересная задача - понять разницу. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=43&mobile=1&tid=1606220]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
161ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 250ms |
0 / 0 |