ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / NESTED LOOP и GroupAggregate
15 сообщений из 40, страница 2 из 2
  2  все
NESTED LOOP и GroupAggregate
    #38884105
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Nitro_JunkieПлюс проблему надо решать уже :(А если добавить скобочки, чтобы явно задать порядок сортировки?
Код: sql
1.
2.
3.
4.
5.
SELECT t0.k0 AS jkey0,
       t0.p0 AS jprop0
  FROM (t_12 t0
  LEFT JOIN Sale_userInvoiceDetail t2 ON t2.key0=t0.k0)
  LEFT JOIN ( ...
...
Рейтинг: 0 / 0
19.02.2015, 15:33
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884666
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
vyegorovNitro_JunkieПлюс проблему надо решать уже :(А если добавить скобочки, чтобы явно задать порядок сортировки?
Код: sql
1.
2.
3.
4.
5.
SELECT t0.k0 AS jkey0,
       t0.p0 AS jprop0
  FROM (t_12 t0
  LEFT JOIN Sale_userInvoiceDetail t2 ON t2.key0=t0.k0)
  LEFT JOIN ( ...



Это уже похоже на перестановку кроватей. Тем более что явный порядок сортировки и задается уменьшением join_collapse_limit (как мы выяснили это как раз помогает). Вопрос почему она сама неправильно определяет порядок.
...
Рейтинг: 0 / 0
20.02.2015, 09:27
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884714
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Nitro_JunkieЭто уже похоже на перестановку кроватей. Тем более что явный порядок сортировки и задается уменьшением join_collapse_limit (как мы выяснили это как раз помогает). Вопрос почему она сама неправильно определяет порядок.
`join_collapse_limit` ограничивает планировщик в перестановке JOIN конструкций. В данном запросе эффект одинаковый (я полагаю?), однако может быть так, что уменьшение `join_collapse_limit` приведет к худшему плану. А скобочки позволяют точечно вправить мозг планировщику.

Я согласен — почему “она сама неправильно определяет порядок” гораздо интереснее. Нужен тест кейс.
...
Рейтинг: 0 / 0
20.02.2015, 10:17
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884738
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
vyegorov,

В общем минимальное что смог пока найти:

Код: sql
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.
EXPLAIN ANALYZE 
SELECT t0.k0 AS jkey0,
       t0.p0 AS jprop0
FROM t_12 t0
LEFT JOIN Sale_userInvoiceDetail t2 ON t2.key0=t0.k0
LEFT JOIN
  (SELECT t18.PriceList_skuPriceListLedger_PriceListLedger AS k0,
          t18.PriceList_fromDateTimePriceListLedger_PriceListLedger AS k1,
          t9.k2 AS k2,
          last(1 ORDER BY t18.PriceList_fromDateTimePriceListLedger_PriceListLedger) AS e0
   FROM PriceList_priceListLedger t18
   JOIN
     (SELECT t7.Sale_skuUserInvoiceDetail_UserInvoiceDetail AS k0,
             t7.Sale_dateTimeUserInvoiceDetail_null AS k1,
             t7.Sale_supplierStockUserInvoiceDetail_null AS k2
      FROM Sale_userInvoiceDetail t7
      JOIN t_12 t19 ON t19.k0=t7.key0
      GROUP BY 1,
               2,
               3) t9 ON t9.k0=t18.PriceList_skuPriceListLedger_PriceListLedger
   JOIN PriceList_priceListLedgerLedgerPriceListTypeStock t20 ON t20.key1=452
   AND t20.key2=t9.k2
   AND t20.key0=t18.key0
   GROUP BY 1,
            2,
            3) t1 ON t1.k0=t2.Sale_skuUserInvoiceDetail_UserInvoiceDetail
AND t1.k1=t2.Sale_dateTimeUserInvoiceDetail_null
AND t1.k2=t2.Sale_supplierStockUserInvoiceDetail_null



Код: sql
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.
"Nested Loop Left Join  (cost=49811.39..51537.50 rows=327 width=10) (actual time=132.394..39976.922 rows=327 loops=1)"
"  ->  Seq Scan on t_12 t0  (cost=0.00..5.27 rows=327 width=10) (actual time=0.004..0.268 rows=327 loops=1)"
"  ->  Hash Right Join  (cost=49811.39..49816.64 rows=1 width=4) (actual time=122.225..122.226 rows=1 loops=327)"
"        Hash Cond: ((t18.pricelist_skupricelistledger_pricelistledger = t2.sale_skuuserinvoicedetail_userinvoicedetail) AND (t18.pricelist_fromdatetimepricelistledger_pricelistledger = t2.sale_datetimeuserinvoicedetail_null) AND (t7.sale_supplierstockuseri (...)"
"        ->  GroupAggregate  (cost=49803.82..49808.68 rows=18 width=16) (actual time=121.241..122.150 rows=548 loops=327)"
"              ->  Sort  (cost=49803.82..49803.86 rows=18 width=16) (actual time=121.209..121.223 rows=557 loops=327)"
"                    Sort Key: t18.pricelist_skupricelistledger_pricelistledger, t18.pricelist_fromdatetimepricelistledger_pricelistledger, t7.sale_supplierstockuserinvoicedetail_null"
"                    Sort Method: quicksort  Memory: 68kB"
"                    ->  Hash Join  (cost=33301.78..49803.44 rows=18 width=16) (actual time=21.264..121.045 rows=557 loops=327)"
"                          Hash Cond: ((t20.key2 = t7.sale_supplierstockuserinvoicedetail_null) AND (t20.key0 = t18.key0))"
"                          ->  Bitmap Heap Scan on pricelist_pricelistledgerledgerpricelisttypestock t20  (cost=6482.11..20388.41 rows=346024 width=8) (actual time=13.714..31.181 rows=346794 loops=327)"
"                                Recheck Cond: (key1 = 452)"
"                                ->  Bitmap Index Scan on pricelist_pricelistledgerledgerpricelisttypestock_key1_key2_idx  (cost=0.00..6395.61 rows=346024 width=0) (actual time=13.499..13.499 rows=346794 loops=327)"
"                                      Index Cond: (key1 = 452)"
"                          ->  Hash  (cost=26629.66..26629.66 rows=12667 width=20) (actual time=19.616..19.616 rows=29946 loops=1)"
"                                Buckets: 2048  Batches: 1  Memory Usage: 1638kB"
"                                ->  Nested Loop  (cost=2483.30..26629.66 rows=12667 width=20) (actual time=0.528..15.984 rows=29946 loops=1)"
"                                      ->  HashAggregate  (cost=2482.87..2486.14 rows=327 width=16) (actual time=0.521..0.577 rows=322 loops=1)"
"                                            ->  Nested Loop  (cost=0.42..2480.42 rows=327 width=16) (actual time=0.013..0.461 rows=327 loops=1)"
"                                                  ->  Seq Scan on t_12 t19  (cost=0.00..5.27 rows=327 width=4) (actual time=0.004..0.017 rows=327 loops=1)"
"                                                  ->  Index Scan using pk_sale_userinvoicedetail on sale_userinvoicedetail t7  (cost=0.42..7.56 rows=1 width=20) (actual time=0.001..0.001 rows=1 loops=327)"
"                                                        Index Cond: (key0 = t19.k0)"
"                                      ->  Index Scan using pricelist_pricelistledger_pricelist_skupricelistledger_pricelis on pricelist_pricelistledger t18  (cost=0.43..73.43 rows=39 width=16) (actual time=0.003..0.038 rows=93 loops=322)"
"                                            Index Cond: (pricelist_skupricelistledger_pricelistledger = t7.sale_skuuserinvoicedetail_userinvoicedetail)"
"        ->  Hash  (cost=7.56..7.56 rows=1 width=20) (actual time=0.014..0.014 rows=1 loops=327)"
"              Buckets: 1024  Batches: 1  Memory Usage: 1kB"
"              ->  Index Scan using pk_sale_userinvoicedetail on sale_userinvoicedetail t2  (cost=0.42..7.56 rows=1 width=20) (actual time=0.011..0.011 rows=1 loops=327)"
"                    Index Cond: (key0 = t0.k0)"
"Total runtime: 39977.730 ms"



Второй внутренний подзапрос все не получается убрать.

Соответственно проблема когда внутри LAST есть ORDER BY, если его убрать все становится хорошо:
Код: sql
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.
"Nested Loop Left Join  (cost=49815.65..50011.40 rows=327 width=10) (actual time=144.767..170.849 rows=327 loops=1)"
"  ->  Seq Scan on t_12 t0  (cost=0.00..5.27 rows=327 width=10) (actual time=0.005..0.021 rows=327 loops=1)"
"  ->  Hash Right Join  (cost=49815.65..49816.22 rows=1 width=4) (actual time=0.521..0.522 rows=1 loops=327)"
"        Hash Cond: ((t18.pricelist_skupricelistledger_pricelistledger = t2.sale_skuuserinvoicedetail_userinvoicedetail) AND (t18.pricelist_fromdatetimepricelistledger_pricelistledger = t2.sale_datetimeuserinvoicedetail_null) AND (t7.sale_supplierstockuseri (...)"
"        ->  HashAggregate  (cost=49808.08..49808.26 rows=18 width=16) (actual time=0.442..0.483 rows=548 loops=327)"
"              ->  Hash Join  (cost=33301.78..49803.44 rows=18 width=16) (actual time=45.934..143.477 rows=557 loops=1)"
"                    Hash Cond: ((t20.key2 = t7.sale_supplierstockuserinvoicedetail_null) AND (t20.key0 = t18.key0))"
"                    ->  Bitmap Heap Scan on pricelist_pricelistledgerledgerpricelisttypestock t20  (cost=6482.11..20388.41 rows=346024 width=8) (actual time=13.913..32.166 rows=346794 loops=1)"
"                          Recheck Cond: (key1 = 452)"
"                          ->  Bitmap Index Scan on pricelist_pricelistledgerledgerpricelisttypestock_key1_key2_idx  (cost=0.00..6395.61 rows=346024 width=0) (actual time=13.695..13.695 rows=346794 loops=1)"
"                                Index Cond: (key1 = 452)"
"                    ->  Hash  (cost=26629.66..26629.66 rows=12667 width=20) (actual time=25.550..25.550 rows=29946 loops=1)"
"                          Buckets: 2048  Batches: 1  Memory Usage: 1638kB"
"                          ->  Nested Loop  (cost=2483.30..26629.66 rows=12667 width=20) (actual time=0.607..21.197 rows=29946 loops=1)"
"                                ->  HashAggregate  (cost=2482.87..2486.14 rows=327 width=16) (actual time=0.599..0.678 rows=322 loops=1)"
"                                      ->  Nested Loop  (cost=0.42..2480.42 rows=327 width=16) (actual time=0.026..0.501 rows=327 loops=1)"
"                                            ->  Seq Scan on t_12 t19  (cost=0.00..5.27 rows=327 width=4) (actual time=0.009..0.024 rows=327 loops=1)"
"                                            ->  Index Scan using pk_sale_userinvoicedetail on sale_userinvoicedetail t7  (cost=0.42..7.56 rows=1 width=20) (actual time=0.001..0.001 rows=1 loops=327)"
"                                                  Index Cond: (key0 = t19.k0)"
"                                ->  Index Scan using pricelist_pricelistledger_pricelist_skupricelistledger_pricelis on pricelist_pricelistledger t18  (cost=0.43..73.43 rows=39 width=16) (actual time=0.004..0.052 rows=93 loops=322)"
"                                      Index Cond: (pricelist_skupricelistledger_pricelistledger = t7.sale_skuuserinvoicedetail_userinvoicedetail)"
"        ->  Hash  (cost=7.56..7.56 rows=1 width=20) (actual time=0.002..0.002 rows=1 loops=327)"
"              Buckets: 1024  Batches: 1  Memory Usage: 1kB"
"              ->  Index Scan using pk_sale_userinvoicedetail on sale_userinvoicedetail t2  (cost=0.42..7.56 rows=1 width=20) (actual time=0.001..0.001 rows=1 loops=327)"
"                    Index Cond: (key0 = t0.k0)"
"Total runtime: 171.233 ms"



При этом что забавно агрегация идет в цикле.
...
Рейтинг: 0 / 0
20.02.2015, 10:41
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884746
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
Nitro_Junkie,

Вообще конечно странно что во втором плане loops = 327 только в HashAggregate, а в первом идет вплоть до Index scan. При этом на самом деле разница только в том что в первом случае GroupAggregate с sort'ом, а во втором HashAggregate.
...
Рейтинг: 0 / 0
20.02.2015, 10:51
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884754
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
Nitro_Junkie,

Собственно видимо в этом и проблем HashAggregate выполняется за 0,57 миллисекунды, а GroupAggregate за 122 миллисекунды. Хотя алгоритмическая сложность у них одинаковая и cost'ы тоже :(
...
Рейтинг: 0 / 0
20.02.2015, 10:54
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884768
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
Nitro_Junkie,

Собственно если сделать enable_sort TO off, который увеличит cost Group Aggregate до бесконечности все тоже становится ОК.

Код: sql
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.
"Hash Left Join  (cost=10000049809.59..10000052292.46 rows=327 width=10) (actual time=134.853..135.372 rows=327 loops=1)"
"  Hash Cond: ((t2.sale_skuuserinvoicedetail_userinvoicedetail = t1.k0) AND (t2.sale_datetimeuserinvoicedetail_null = t1.k1) AND (t2.sale_supplierstockuserinvoicedetail_null = t1.k2))"
"  ->  Nested Loop Left Join  (cost=0.42..2479.60 rows=327 width=26) (actual time=0.010..0.489 rows=327 loops=1)"
"        ->  Seq Scan on t_12 t0  (cost=0.00..5.27 rows=327 width=10) (actual time=0.004..0.016 rows=327 loops=1)"
"        ->  Index Scan using pk_sale_userinvoicedetail on sale_userinvoicedetail t2  (cost=0.42..7.56 rows=1 width=20) (actual time=0.001..0.001 rows=1 loops=327)"
"              Index Cond: (key0 = t0.k0)"
"  ->  Hash  (cost=10000049808.86..10000049808.86 rows=18 width=16) (actual time=134.835..134.835 rows=548 loops=1)"
"        Buckets: 1024  Batches: 1  Memory Usage: 28kB"
"        ->  Subquery Scan on t1  (cost=10000049803.82..10000049808.86 rows=18 width=16) (actual time=133.817..134.750 rows=548 loops=1)"
"              ->  GroupAggregate  (cost=10000049803.82..10000049808.68 rows=18 width=24) (actual time=133.816..134.709 rows=548 loops=1)"
"                    ->  Sort  (cost=10000049803.82..10000049803.86 rows=18 width=24) (actual time=133.760..133.772 rows=557 loops=1)"
"                          Sort Key: t18.pricelist_skupricelistledger_pricelistledger, t18.pricelist_fromdatetimepricelistledger_pricelistledger, t7.sale_supplierstockuserinvoicedetail_null"
"                          Sort Method: quicksort  Memory: 68kB"
"                          ->  Hash Join  (cost=33301.78..49803.44 rows=18 width=24) (actual time=41.954..133.595 rows=557 loops=1)"
"                                Hash Cond: ((t20.key2 = t7.sale_supplierstockuserinvoicedetail_null) AND (t20.key0 = t18.key0))"
"                                ->  Bitmap Heap Scan on pricelist_pricelistledgerledgerpricelisttypestock t20  (cost=6482.11..20388.41 rows=346024 width=8) (actual time=14.823..30.802 rows=346794 loops=1)"
"                                      Recheck Cond: (key1 = 452)"
"                                      ->  Bitmap Index Scan on pricelist_pricelistledgerledgerpricelisttypestock_key1_key2_idx  (cost=0.00..6395.61 rows=346024 width=0) (actual time=14.613..14.613 rows=346794 loops=1)"
"                                            Index Cond: (key1 = 452)"
"                                ->  Hash  (cost=26629.66..26629.66 rows=12667 width=28) (actual time=19.935..19.935 rows=29946 loops=1)"
"                                      Buckets: 2048  Batches: 1  Memory Usage: 1638kB"
"                                      ->  Nested Loop  (cost=2483.30..26629.66 rows=12667 width=28) (actual time=0.529..16.076 rows=29946 loops=1)"
"                                            ->  HashAggregate  (cost=2482.87..2486.14 rows=327 width=16) (actual time=0.523..0.570 rows=322 loops=1)"
"                                                  ->  Nested Loop  (cost=0.42..2480.42 rows=327 width=16) (actual time=0.014..0.445 rows=327 loops=1)"
"                                                        ->  Seq Scan on t_12 t19  (cost=0.00..5.27 rows=327 width=4) (actual time=0.004..0.016 rows=327 loops=1)"
"                                                        ->  Index Scan using pk_sale_userinvoicedetail on sale_userinvoicedetail t7  (cost=0.42..7.56 rows=1 width=20) (actual time=0.001..0.001 rows=1 loops=327)"
"                                                              Index Cond: (key0 = t19.k0)"
"                                            ->  Index Scan using pricelist_pricelistledger_pricelist_skupricelistledger_pricelis on pricelist_pricelistledger t18  (cost=0.43..73.43 rows=39 width=24) (actual time=0.003..0.038 rows=93 loops=322)"
"                                                  Index Cond: (pricelist_skupricelistledger_pricelistledger = t7.sale_skuuserinvoicedetail_userinvoicedetail)"
"Total runtime: 135.835 ms"



Но не хочется включать enable_sort на весь сервер. :(
...
Рейтинг: 0 / 0
20.02.2015, 11:14
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884788
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Nitro_Junkie,

Мне кажется, что планировщик неверно оценивает агрегатную функцию с `ORDER BY`.
Поиграться бы с этим случаем. Вы какой-то дамп можете предоставить?
...
Рейтинг: 0 / 0
20.02.2015, 11:30
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884812
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
vyegorovNitro_Junkie,

Мне кажется, что планировщик неверно оценивает агрегатную функцию с `ORDER BY`.
Поиграться бы с этим случаем. Вы какой-то дамп можете предоставить?

Агрегатная функция в плане вообще не показывается. Может вы знаете где еще можно информацию достать.

Но вообще что интересно у Hash Join в обоих планах и actual time и rows и cost одинаковые, но почему у HashAggregate, который идет строкой выше actual time 0.51, то есть деленное на loops, а у GroupAggregate нет - загадка. То есть я даже не могу догнать как именно он выполняет эти планы, не то что почему он их так оценивает.
...
Рейтинг: 0 / 0
20.02.2015, 11:43
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884882
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Nitro_Junkie,

Агрегатная функция выражается в узлах `GroupAggregate` (который требует отсортированных данных) или `HashAggregate`, который быстрый и потому предпочтительней.
Добавляя `ORDER BY` в агрегатную функцию вы задаете порядок, который требует сортировку. Ну и при таком раскладе можно использовать `GroupAgg`, т.к. данные уже отсортированы. Но планировщик (мне кажется) что-то не учитывает и запихивает `Sort`+`GroupAgg` в цикл, что выходит очень дорого. И вот этот момент хотелось бы прояснить у разработчиков.
(От сортировки можно было бы избавиться через индекс, но у вас используются колонки из разных таблиц...)

Общее время потраченное на узел считается как `actual time` * `loops`.
Хотя на самом деле во время исполнения регистрируется общее время, а потом делиться на кол-во проходов. Тоже самое и для кол-ва реальных записей возвращенных узлом. Это иногда приводит к тому, что записи показывается как `0`, если некоторые проходы были безрезультатны.

В случае с `HashAggregate` умножаем 0.483 на 327 и получаем 157ms, что похоже на общее время исполнения.
Для `GroupAggregate` умножаем 122.150 (что уже почти равняется общему времени для `HashAgg`) на 327 и получаем 39943.05 (40 секунд).
...
Рейтинг: 0 / 0
20.02.2015, 12:40
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38884926
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
vyegorovNitro_Junkie,

Агрегатная функция выражается в узлах `GroupAggregate` (который требует отсортированных данных) или `HashAggregate`, который быстрый и потому предпочтительней.
Добавляя `ORDER BY` в агрегатную функцию вы задаете порядок, который требует сортировку. Ну и при таком раскладе можно использовать `GroupAgg`, т.к. данные уже отсортированы. Но планировщик (мне кажется) что-то не учитывает и запихивает `Sort`+`GroupAgg` в цикл, что выходит очень дорого. И вот этот момент хотелось бы прояснить у разработчиков.
(От сортировки можно было бы избавиться через индекс, но у вас используются колонки из разных таблиц...)

Общее время потраченное на узел считается как `actual time` * `loops`.
Хотя на самом деле во время исполнения регистрируется общее время, а потом делиться на кол-во проходов. Тоже самое и для кол-ва реальных записей возвращенных узлом. Это иногда приводит к тому, что записи показывается как `0`, если некоторые проходы были безрезультатны.

В случае с `HashAggregate` умножаем 0.483 на 327 и получаем 157ms, что похоже на общее время исполнения.
Для `GroupAggregate` умножаем 122.150 (что уже почти равняется общему времени для `HashAgg`) на 327 и получаем 39943.05 (40 секунд).

Попытался поиграться с планами, но в других случаях планировщик всегда вставляет, что-то типа следующего:

[SQL]
" -> Materialize (cost=6164744.96..6164838.15 rows=327 width=16) (actual time=80.627..80.630 rows=96 loops=327)"
" -> Subquery Scan on t1 (cost=6164744.96..6164836.52 rows=327 width=16) (actual time=26364.901..26365.295 rows=96 loops=1)"
" -> GroupAggregate (cost=6164744.96..6164833.25 rows=327 width=24) (actual time=26364.900..26365.286 rows=96 loops=1)"
[/SQL]

Почему он здесь этого не делает неясно. Более того я тогда вообще не понимаю пункта плана Materialize. Ведь в правильном исходном плане Materialize'а нет, но де-факто он происходит, как видим Hash Join идет 1 раз.
...
Рейтинг: 0 / 0
20.02.2015, 13:07
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38885037
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Nitro_Junkie,

`Materialize` значит, что планировщик понимает, что одни и те же данные будут сканироваться некоторое число раз, и находит, что ему дешевле сохранить результат под-плана, а не вычислять его каждый раз заново. Естественно, такое возможно, если под-план всегда возвращает одинаковый результат.

И я полагаю, что это стало возможным потому, что вы убрали функцию `ANYVALUE()` (как ранее указывал Максим).
...
Рейтинг: 0 / 0
20.02.2015, 14:23
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38885104
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
vyegorovNitro_Junkie,

`Materialize` значит, что планировщик понимает, что одни и те же данные будут сканироваться некоторое число раз, и находит, что ему дешевле сохранить результат под-плана, а не вычислять его каждый раз заново. Естественно, такое возможно, если под-план всегда возвращает одинаковый результат.

И я полагаю, что это стало возможным потому, что вы убрали функцию `ANYVALUE()` (как ранее указывал Максим).

Тогда почему "в правильном исходном плане Materialize'а нет, но де-факто он происходит, как видим Hash Join идет 1 раз"

ANYVALUE по моим наблюдениям никак не влияет на планы. Что он есть его нет...
...
Рейтинг: 0 / 0
20.02.2015, 15:01
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38885226
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Nitro_JunkieТогда почему "в правильном исходном плане Materialize'а нет, но де-факто он происходит, как видим Hash Join идет 1 раз"
Я не знаю. Предполагаю, что особенности работы с хэш-таблицей позволяют построить ее один раз (на основании результатов HashJoin) и затем просто возвращать агрегированные данные. Потому HashJoin loops=1, но вышестоящий HashAggregate loops=327.
...
Рейтинг: 0 / 0
20.02.2015, 16:28
| Ответить | Цитировать | Написать  
NESTED LOOP и GroupAggregate
    #38889002
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
vyegorovNitro_JunkieТогда почему "в правильном исходном плане Materialize'а нет, но де-факто он происходит, как видим Hash Join идет 1 раз"
Я не знаю. Предполагаю, что особенности работы с хэш-таблицей позволяют построить ее один раз (на основании результатов HashJoin) и затем просто возвращать агрегированные данные. Потому HashJoin loops=1, но вышестоящий HashAggregate loops=327.
а для сортировки ее надо 327 раз джойнить? ммм
...
Рейтинг: 0 / 0
26.02.2015, 01:26
| Ответить | Цитировать | Написать  
15 сообщений из 40, страница 2 из 2
  2  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / NESTED LOOP и GroupAggregate
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38884812&tid=1998148]:
 0ms
get settings:
 7ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 46ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 197ms
total:  343ms
созд. / загр.: 343ms
x
x
Закрыть


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