Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
Собственно сама проблема описана в другом топике и похоже решения не имеет . http://sql.ru/forum/actualthread.aspx?tid=625388 В двух словах: В одном ORM сущности можно представить в некой иерархии на подобии той которая используется в постгресте , но иммулируется простыми запросами с "left outer join". Что бы ORM узнала какому типу записи принадлежит та или инная запись она запрашивает ВСЕ ТАБЛИЦЫ ВХОДЯЩИЕ В ИЕРАРХИЮ. Причом не только родительских и дочерних по отношению с запрашиваемым типом ... а всех :-( Вот пример с тремя табличками в иерархии: Код: 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. На пустых табличках без статистики план такой ... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Собственно меня интересует ... не поплохеет постгресу когда в таких запросах будут участвовать 50-100 таблиц ??? Может уже кто то такое пробовал ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2008, 16:33 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
на практике не встречался но 50 join ов эт наверное перебор требует пересмотрения структуры имхо. Хороший анализ ООП в RDBMS а кроме всего прочего Google: ООП RDBMS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2008, 17:08 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
sherzod_, спасибо ... я конечно на досуге почитаю , но всёравно буду пользоваться хибером :-( Вот есть у меня результаты: При джойне с табличками в которых всего по одой колонке +ключь: 20 таблиц 25 мс. 30 время растёт до 33 мс 50таблиц 67-69 выборка одного поля 62-63мс с одной таблички Потом добавил 9 полей к каждой табличке... итого 50*9=450 колонок в выборке. 50таблиц время выросло на 130-140 мс такой же запрос , но без выборки всех полей 80мс. (почему так ? наверное планировать тяжелее ?) ЗЫ постгрес процес не потребляет астрономически много памяти на парсинг, обработку .... процес до 7МБ памяти сожрал на несколько запусков такого запроса ... при последущих запусках память особо не кушал. ЗЫ2 Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2008, 17:31 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
ответил в /topic/625388 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2008, 19:35 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
Чего сложного в 50 JOIN-ах, если они конечно по FK==>PK и на PK есть индексы ? Там только у оптимизатора может крышу сносить от изобилия таблиц, ну да всё одно он более 4-10 таблиц не берёт в расчёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2009, 16:39 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
MasterZivТам только у оптимизатора может крышу сносить от изобилия таблиц, ну да всё одно он более 4-10 таблиц не берёт в расчёт.в pg - берёт, просто если в запросе join таблиц больше чем geqo_threshold (по умолчанию 12) - то для планирования будет использован другой алгоритм - geqo (Genetic Query Optimization). У это алгоритма есть одна особенность, так как в этом генетическом алгоритме используются случайные значения, то один и тот же запрос для одних и тех же данных может давать слегка различные планы выполнения + так как чудес не бывает, geqo не всегда может найти самый оптимальный план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2009, 18:21 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
Ёш пишет: > используются случайные значения, то один и тот же запрос для одних и тех > же данных может давать слегка различные планы выполнения + так как чудес > не бывает, geqo не всегда может найти самый оптимальный план. Вообще, оптимизатор не должен искать самый оптимальный план. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2009, 18:31 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
Ёшв pg - берёт, просто если в запросе join таблиц больше чем geqo_threshold (по умолчанию 12) - то для планирования будет использован другой алгоритм - geqo (Genetic Query Optimization). У это алгоритма есть одна особенность, так как в этом генетическом алгоритме используются случайные значения, то один и тот же запрос для одних и тех же данных может давать слегка различные планы выполнения + так как чудес не бывает, geqo не всегда может найти самый оптимальный план. В моём случае было так что выбирался всегда один и тот-же план .... хотя практически все таблички были пустыми ... может если залить нормальные данные , то ситуация изменилась бы :-) кто знает ... Есть ещо одно ... сам хибер (в варианте с аннотациями) мог задавать более нормальные запросы ... , но он тоже на это дело положил :-( , Получалось или брать маппинг через хмл файлы (там происходит два запроса : один к главной табличке, а второй уже вытягивает всё наследие объекта , что в итоге опрашивает намного меньше таблиц в запросе ) или терпеть такие запросы и планировать переход на другой JPA :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2009, 14:00 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
KRED пишет: > В моём случае было так что выбирался всегда один и тот-же план .... хотя > практически все таблички были пустыми ... может если залить нормальные > данные , то ситуация изменилась бы :-) кто знает ... Я знаю. Изменилась бы. > Есть ещо одно ... сам хибер (в варианте с аннотациями) мог задавать > более нормальные запросы ... , но он тоже на это дело положил :-( , > Получалось или брать маппинг через хмл файлы (там происходит два запроса > : один к главной табличке, а второй уже вытягивает всё наследие объекта > , что в итоге опрашивает намного меньше таблиц в запросе ) или терпеть > такие запросы и планировать переход на другой JPA :-( Маппинг не зависит от способа его описания : и через XML, и через Annotations можно описать все виды маппинга. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2009, 16:37 |
|
||
|
Гигансткий запрос ...
|
|||
|---|---|---|---|
|
#18+
MasterZiv > Есть ещо одно ... сам хибер (в варианте с аннотациями) мог задавать > более нормальные запросы ... , но он тоже на это дело положил :-( , > Получалось или брать маппинг через хмл файлы (там происходит два запроса > : один к главной табличке, а второй уже вытягивает всё наследие объекта > , что в итоге опрашивает намного меньше таблиц в запросе ) или терпеть > такие запросы и планировать переход на другой JPA :-( Маппинг не зависит от способа его описания : и через XML, и через Annotations можно описать все виды маппинга. В случае с наследованием , то через XML-mapping можно добиться тех действий что я описал , а через аннотации такой функционал по доке работать должен (это в доке описано как рекомендательная возможность, которую не обязательно осуществлять в реализации), но в реализации хибера такое не работает ... по крайней мере сейчас . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2009, 12:38 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=254&tid=2003715]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 271ms |
| total: | 412ms |

| 0 / 0 |
