ReSQL.ru
     
powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Отсутствие JPPD оптимизации как класса
8 сообщений из 8, страница 1 из 1
Отсутствие JPPD оптимизации как класса
    #39848155
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nitro_Junkie
Участник
Я с 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:01
| Ответить | Цитировать | Написать  
Отсутствие JPPD оптимизации как класса
    #39848165
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
Nitro_Junkie,

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

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

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

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

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

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

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

Ну и тем более непонятно, раз lateral они поддерживают, почему предикаты самим не проталкивать.
...
Рейтинг: 0 / 0
12.08.2019, 14:16
| Ответить | Цитировать | Написать  
Отсутствие JPPD оптимизации как класса
    #39988112
Pablos2038
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pablos2038
Гость
Добрый день. А не подскажете, возможен ли 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:03
| Ответить | Цитировать | Написать  
Отсутствие JPPD оптимизации как класса
    #39988141
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
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, 12:49
| Ответить | Цитировать | Написать  
Отсутствие JPPD оптимизации как класса
    #39988398
Pablos2038
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pablos2038
Гость
Да я указываю, extensions='hstore' , версия одинаковая 1.4
Более того, для чистоты эксперимента я даже "завернул" сервер сам на себя как внешний) так что там версии уж точно одинаковые.
...
Рейтинг: 0 / 0
10.08.2020, 20:32
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Отсутствие JPPD оптимизации как класса
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&fpage=24&tid=1994533]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 58ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 284ms
total:  439ms
созд. / загр.: 439ms
x
x
Закрыть


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