|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
Глюк оптимизатора В sqexplain.out видно, что фильтр "type_post >= 3" никак не задействован.... Код: 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.
При изменении текста where с внесением "type_post >= 3" внутрь OR и для id_account_kr и для id_account_db - исправляет ситуацию... P.S: Воссоздать "в тепличных условиях" не получается (т.е. небольшой тестовый пример, который бы воспроизвёл ситуацию). Используем для тестирования: Informix IDS Dynamic Server Developer Edition 11.5 for Linux (x86) RHEL 4, 64bit Version 1150FC3DE Informix IDS Dynamic Server Enterprise Edition - TimeLimited 11.5 for Linux (x86) RHEL 4, 64bit Version 1150FC3TL Кто-бы PMR оформил? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2009, 13:38 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
1. Проблема не воспроизводилась при некотором расширением диапазона фильтрации по дате 2. Перестала воспроизводиться и на "волнующих запросах" после UPDATE STATISTICS HIGH FOR TABLE sm_posting... Странно, всегда думал, что UPDATE STATISTICS должен влиять только на производительность запроса, но никак на корректность плана.... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2009, 17:37 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
АнатоЛой1. Проблема не воспроизводилась при некотором расширением диапазона фильтрации по дате 2. Перестала воспроизводиться и на "волнующих запросах" после UPDATE STATISTICS HIGH FOR TABLE sm_posting... Странно, всегда думал, что UPDATE STATISTICS должен влиять только на производительность запроса, но никак на корректность плана.... Интересно, как производительность запроса может измениться без изменения плана... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 00:04 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
ВыбегаллоИнтересно, как производительность запроса может измениться без изменения плана... Интересно, как план может измениться без изменения статистики... Ж8-) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 12:41 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
Видимо имеется в виду, что UPDATE STATISTICS должен влиять на выбор наиболее эффктивного плана выполнения запроса, не влияя на результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 12:45 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
ВыбегаллоИнтересно, как производительность запроса может измениться без изменения плана... Под "производительностью запроса" что подразумевается ? - реальное время выполнения запроса - условные "попугаи" в плане - что то другое... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 14:49 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
Unknownsvat2Выбегалло Интересно, как производительность запроса может измениться без изменения плана... Интересно, как план может измениться без изменения статистики... Ж8-) Например, с помощью директив :) тогда для полноты картины еще давайте и изменение версии IDS учитывать в ряду причин :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 15:57 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
ВыбегаллоАнатоЛой1. Проблема не воспроизводилась при некотором расширением диапазона фильтрации по дате 2. Перестала воспроизводиться и на "волнующих запросах" после UPDATE STATISTICS HIGH FOR TABLE sm_posting... Странно, всегда думал, что UPDATE STATISTICS должен влиять только на производительность запроса, но никак на корректность плана.... Интересно, как производительность запроса может измениться без изменения плана... Повторюсь, если не осознали "степень/важность/глубину"... "В sqexplain.out видно, что фильтр "type_post >= 3" никак не задействован...." Тот факт, что type_post никак не фигурирует в плане запроса, на практике выглядел как "условие type_post >= 3 вообще не проверяется при выполнении выборки" То есть проблема была не в производительности плана, а в некорректности работы запроса. После выполнения запроса в отобранные данные попали строки с type_post = 1, что никак не соответствует фильтру. Вооооооот. И после эмпирического UPDATE STAT проблема пропала... Отчего неприятный осадок в душе ещё больше сгустился... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 19:12 |
|
Ошибка в IDS11.50.xC3:
|
|||
---|---|---|---|
#18+
АнатоЛойВыбегаллоАнатоЛой1. Проблема не воспроизводилась при некотором расширением диапазона фильтрации по дате 2. Перестала воспроизводиться и на "волнующих запросах" после UPDATE STATISTICS HIGH FOR TABLE sm_posting... Странно, всегда думал, что UPDATE STATISTICS должен влиять только на производительность запроса, но никак на корректность плана.... Интересно, как производительность запроса может измениться без изменения плана... Повторюсь, если не осознали "степень/важность/глубину"... "В sqexplain.out видно, что фильтр "type_post >= 3" никак не задействован...." Тот факт, что type_post никак не фигурирует в плане запроса, на практике выглядел как "условие type_post >= 3 вообще не проверяется при выполнении выборки" То есть проблема была не в производительности плана, а в некорректности работы запроса. После выполнения запроса в отобранные данные попали строки с type_post = 1, что никак не соответствует фильтру. Вооооооот. И после эмпирического UPDATE STAT проблема пропала... Отчего неприятный осадок в душе ещё больше сгустился... баг. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2009, 19:52 |
|
|
start [/forum/topic.php?fid=44&fpage=30&tid=1607848]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
others: | 330ms |
total: | 484ms |
0 / 0 |