Гость
Войти | Профиль | Очистить
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Отсутствие JPPD оптимизации как класса / 8 сообщений из 8, страница 1 из 1
12.08.2019, 11:01
    #39848155
Nitro_Junkie
Nitro_Junkie
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
Я с PostgreSQL работаю очень давно. Собственно тут с десяток моих тем с косяками оптимизатора.

Но только, когда учавствовал в написании этой статьи, понял что в PostgreSQL отсутствует одна супер важная оптимизация - Join Predicate Push Down:

Запрос:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT income.quantity
	FROM product
	JOIN
		(SELECT product, SUM(quantity) AS quantity
			FROM shipmentDetail 
			JOIN shipment ON shipmentDetail.shipment = shipment.id
			GROUP BY product
		) income ON income.product = product.id
	WHERE product."group" = 54



План запроса:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
"Hash Join  (cost=252901.05..254168.34 rows=49 width=32) (actual time=11580.152..11607.399 rows=48 loops=1)"
"  Hash Cond: (shipmentdetail.product = product.id)"
"  ->  HashAggregate  (cost=252763.56..253394.04 rows=50439 width=36) (actual time=11579.912..11603.696 rows=50000 loops=1)"
"        Group Key: shipmentdetail.product"
"        ->  Hash Join  (cost=2985.02..202764.28 rows=9999855 width=9) (actual time=46.117..5967.219 rows=10000001 loops=1)"
"              Hash Cond: (shipmentdetail.shipment = shipment.id)"
"              ->  Seq Scan on shipmentdetail  (cost=0.00..173528.55 rows=9999855 width=13) (actual time=0.017..1158.157 rows=10000001 loops=1)"
"              ->  Hash  (cost=1735.01..1735.01 rows=100001 width=4) (actual time=45.798..45.798 rows=100001 loops=1)"
"                    Buckets: 131072  Batches: 1  Memory Usage: 4540kB"
"                    ->  Seq Scan on shipment  (cost=0.00..1735.01 rows=100001 width=4) (actual time=0.018..19.940 rows=100001 loops=1)"
"  ->  Hash  (cost=136.88..136.88 rows=49 width=4) (actual time=0.202..0.202 rows=48 loops=1)"
"        Buckets: 1024  Batches: 1  Memory Usage: 10kB"
"        ->  Bitmap Heap Scan on product  (cost=4.67..136.88 rows=49 width=4) (actual time=0.045..0.181 rows=48 loops=1)"
"              Recheck Cond: ("group" = 54)"
"              Heap Blocks: exact=46"
"              ->  Bitmap Index Scan on product_group  (cost=0.00..4.66 rows=49 width=0) (actual time=0.025..0.025 rows=48 loops=1)"
"                    Index Cond: ("group" = 54)"
"Planning Time: 0.658 ms"
"Execution Time: 11608.602 ms"



То есть PostgreSQL не догадывается что надо бежать только по товарам с группой 54.

Она реально отсутствует или каким-то волшебным образом включается? Потому как без нее те же представления бесполезны чуть меньше чем полностью.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.08.2019, 11:16
    #39848165
Melkij
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
Nitro_Junkie,

для join есть и работает.
А вот для группировки - нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.08.2019, 11:34
    #39848183
Nitro_Junkie
Nitro_Junkie
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
MelkijNitro_Junkie,

для join есть и работает.
А вот для группировки - нет.

Для join там просто inline query идет. Это принципиально другой механизм в общем-то (не JPPD).

Ну и группировка как бы одна из базовых операций. То есть без нее даже представление остатков не сделаешь.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.08.2019, 13:15
    #39848274
fte
fte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
Nitro_Junkie,

А join lateral , разве не поможет ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.08.2019, 14:16
    #39848320
Nitro_Junkie
Nitro_Junkie
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
fteNitro_Junkie,

А join lateral , разве не поможет ?

Частично поможет. Но например не с представлениями. Плюс по сути тем самым форсируется nested loop join. А это по большому счету должно само СУБД решать (так как зависит от статистики).

Ну и тем более непонятно, раз lateral они поддерживают, почему предикаты самим не проталкивать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2020, 12:03
    #39988112
Pablos2038
Pablos2038
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
Добрый день. А не подскажете, возможен ли pushdown предикатов для колонок hstore. У меня на тесте вместо pushdown ставит локальный фильтр.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
# explain ( verbose, costs off )
select title, attr -> 'weight' AS weight
FROM fdw_pbls_test.pbls_test_books
WHERE attr ? 'publisher';

                         QUERY PLAN
------------------------------------------------------------
 Foreign Scan on fdw_pbls_test.pbls_test_books
   Output: title, (attr -> 'weight'::text)
   Filter: (pbls_test_books.attr ? 'publisher'::text)
   Remote SQL: SELECT title, attr FROM sbrf.pbls_test_books
(4 rows)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2020, 12:49
    #39988141
Melkij
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
Pablos2038,

Поясните FDW, что вы ожидаете совместимое поведение hstore на обоих серверах:

https://www.postgresql.org/docs/current/postgres-fdw.html
extensions

This option is a comma-separated list of names of PostgreSQL extensions that are installed, in compatible versions, on both the local and remote servers. Functions and operators that are immutable and belong to a listed extension will be considered shippable to the remote server. This option can only be specified for foreign servers, not per-table.

When using the extensions option, it is the user's responsibility that the listed extensions exist and behave identically on both the local and remote servers. Otherwise, remote queries may fail or behave unexpectedly.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2020, 20:32
    #39988398
Pablos2038
Pablos2038
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Отсутствие JPPD оптимизации как класса
Да я указываю, extensions='hstore' , версия одинаковая 1.4
Более того, для чистоты эксперимента я даже "завернул" сервер сам на себя как внешний) так что там версии уж точно одинаковые.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Отсутствие JPPD оптимизации как класса / 8 сообщений из 8, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 144ms
Закрыть
start [/forum/topic.php?fid=53&mobile=1&tid=1994533]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 36ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 47ms
get tp. blocked users:
 1ms
others: 15ms
total:  144ms
x
x
Закрыть


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