powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Гигансткий запрос ...
10 сообщений из 10, страница 1 из 1
Гигансткий запрос ...
    #35728289
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Собственно сама проблема описана в другом топике и похоже решения не имеет .
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.
/* select
        page 
    from
        Url page 
    where
        page.url_str='index.html' 
        and page.customer.host='www'   */ select
            url0_.pr_id as pr1_3_,
            url0_.customer as customer3_,
            url0_.lastupdate as lastupdate3_,
            url0_.menuitem as menuitem3_,
            url0_.url_str as url3_3_,
            url0_1_.bin_daten as bin1_4_,
            url0_1_.mime_type as mime2_4_,
            url0_2_.title as title5_,
            url0_2_.xml_daten as xml2_5_,
            case 
                when url0_1_.pr_id is not null then  1  
                when url0_2_.pr_id is not null then  2  
                when url0_.pr_id is not null then  0  
            end as clazz_ 
        from
            public.url url0_ 
        left outer join
            public.rossource url0_1_ 
                on url0_.pr_id=url0_1_.pr_id 
        left outer join
            public.page url0_2_ 
                on url0_.pr_id=url0_2_.pr_id,
            public.customer customer1_ 
        where
            url0_.customer=customer1_.pr 
            and url0_.url_str='index.html' 
            and customer1_.host='www'

На пустых табличках без статистики план такой ...
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
 Nested Loop Left Join  (cost= 0 . 00 .. 33 . 11  rows= 1  width= 1542 ) (actual time= 0 . 096 .. 0 . 099  rows= 1  loops= 1 )
   ->  Nested Loop Left Join  (cost= 0 . 00 .. 24 . 83  rows= 1  width= 990 ) (actual time= 0 . 086 .. 0 . 089  rows= 1  loops= 1 )
         ->  Nested Loop  (cost= 0 . 00 .. 16 . 55  rows= 1  width= 536 ) (actual time= 0 . 077 .. 0 . 079  rows= 1  loops= 1 )
               ->  Index Scan using customer_host_key on customer customer1_  (cost= 0 . 00 .. 8 . 27  rows= 1  width= 4 ) (actual time= 0 . 050 .. 0 . 050  rows= 1  loops= 1 )
                     Index Cond: ((host)::text = 'www'::text)
               ->  Index Scan using url_customer_key on url url0_  (cost= 0 . 00 .. 8 . 27  rows= 1  width= 536 ) (actual time= 0 . 019 .. 0 . 020  rows= 1  loops= 1 )
                     Index Cond: ((url0_.customer = customer1_.pr) AND ((url0_.url_str)::text = 'index.html'::text))
         ->  Index Scan using page_pkey on page url0_2_  (cost= 0 . 00 .. 8 . 27  rows= 1  width= 454 ) (actual time= 0 . 009 .. 0 . 010  rows= 1  loops= 1 )
               Index Cond: (url0_.pr_id = url0_2_.pr_id)
   ->  Index Scan using rossource_pkey on rossource url0_1_  (cost= 0 . 00 .. 8 . 27  rows= 1  width= 552 ) (actual time= 0 . 006 .. 0 . 006  rows= 0  loops= 1 )
         Index Cond: (url0_.pr_id = url0_1_.pr_id)
 Total runtime:  0 . 235  ms
( 12  rows)

Собственно меня интересует ... не поплохеет постгресу когда в таких запросах будут участвовать 50-100 таблиц ???

Может уже кто то такое пробовал ?
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35728389
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
на практике не встречался
но 50 join ов эт наверное перебор
требует пересмотрения структуры имхо.

Хороший анализ ООП в RDBMS
а кроме всего прочего Google: ООП RDBMS
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35728440
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
hosting=# select * from customer where pr =  1  ;
 pr | host | name_ | template
----+------+-------+----------
   1  | ... | .... |         1 
( 1  row)

Time:  0 . 371  ms
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35728766
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ответил в /topic/625388
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35762896
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чего сложного в 50 JOIN-ах, если они конечно по FK==>PK и на PK есть индексы ?

Там только у оптимизатора может крышу сносить от изобилия таблиц, ну да всё одно он более 4-10 таблиц не берёт в расчёт.
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35762949
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivТам только у оптимизатора может крышу сносить от изобилия таблиц, ну да всё одно он более 4-10 таблиц не берёт в расчёт.в pg - берёт, просто если в запросе join таблиц больше чем geqo_threshold (по умолчанию 12) - то для планирования будет использован другой алгоритм - geqo (Genetic Query Optimization). У это алгоритма есть одна особенность, так как в этом генетическом алгоритме используются случайные значения, то один и тот же запрос для одних и тех же данных может давать слегка различные планы выполнения + так как чудес не бывает, geqo не всегда может найти самый оптимальный план.
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35762957
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ёш пишет:

> используются случайные значения, то один и тот же запрос для одних и тех
> же данных может давать слегка различные планы выполнения + так как чудес
> не бывает, geqo не всегда может найти самый оптимальный план.

Вообще, оптимизатор не должен искать самый оптимальный план.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35763392
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ёшв pg - берёт, просто если в запросе join таблиц больше чем geqo_threshold (по умолчанию 12) - то для планирования будет использован другой алгоритм - geqo (Genetic Query Optimization). У это алгоритма есть одна особенность, так как в этом генетическом алгоритме используются случайные значения, то один и тот же запрос для одних и тех же данных может давать слегка различные планы выполнения + так как чудес не бывает, geqo не всегда может найти самый оптимальный план.


В моём случае было так что выбирался всегда один и тот-же план .... хотя практически все таблички были пустыми ... может если залить нормальные данные , то ситуация изменилась бы :-) кто знает ...

Есть ещо одно ... сам хибер (в варианте с аннотациями) мог задавать более нормальные запросы ... , но он тоже на это дело положил :-( , Получалось или брать маппинг через хмл файлы (там происходит два запроса : один к главной табличке, а второй уже вытягивает всё наследие объекта , что в итоге опрашивает намного меньше таблиц в запросе ) или терпеть такие запросы и планировать переход на другой JPA :-(
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35763467
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KRED пишет:

> В моём случае было так что выбирался всегда один и тот-же план .... хотя
> практически все таблички были пустыми ... может если залить нормальные
> данные , то ситуация изменилась бы :-) кто знает ...

Я знаю. Изменилась бы.

> Есть ещо одно ... сам хибер (в варианте с аннотациями) мог задавать
> более нормальные запросы ... , но он тоже на это дело положил :-( ,
> Получалось или брать маппинг через хмл файлы (там происходит два запроса
> : один к главной табличке, а второй уже вытягивает всё наследие объекта
> , что в итоге опрашивает намного меньше таблиц в запросе ) или терпеть
> такие запросы и планировать переход на другой JPA :-(

Маппинг не зависит от способа его описания : и через XML, и через Annotations
можно описать все виды маппинга.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Гигансткий запрос ...
    #35764372
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
> Есть ещо одно ... сам хибер (в варианте с аннотациями) мог задавать
> более нормальные запросы ... , но он тоже на это дело положил :-( ,
> Получалось или брать маппинг через хмл файлы (там происходит два запроса
> : один к главной табличке, а второй уже вытягивает всё наследие объекта
> , что в итоге опрашивает намного меньше таблиц в запросе ) или терпеть
> такие запросы и планировать переход на другой JPA :-(

Маппинг не зависит от способа его описания : и через XML, и через Annotations
можно описать все виды маппинга.


В случае с наследованием , то через XML-mapping можно добиться тех действий что я описал , а через аннотации такой функционал по доке работать должен (это в доке описано как рекомендательная возможность, которую не обязательно осуществлять в реализации), но в реализации хибера такое не работает ... по крайней мере сейчас .
...
Рейтинг: 0 / 0
10 сообщений из 10, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Гигансткий запрос ...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]