как у оракла? я не сталкивался...
Не то, чтобы их совсем не было (есть одно расшырение от японцэв) -- просто оно как-то на практике никогда и не нужно. Заставить оптимизатор понимать что происходит обычно можно другими средствами -- статистикой, костами, переделкой запросов.
Ну, я не в глобальном смысле "такое расшырение не нужно" (у меня тут мнение, что лучшэ чтобы было) -- но руки его ставить обычно не доходят, поскольку всё и так обходится.
Ок, а что бы в данном случае сделать, заменить ANY(ARRAY()) на IN -- это первое что я порывался сделать, ибо читается сильно лучше с IN, что ещё?
Для начала -- посмотреть с enable_seqscan = off; Кстати, это ssd, видимо? А random_page_cost в 1.2 (ну, плюс-минус, не 4) -- выставлен? Сервер вообще настроен? Я так подозреваю, что shared_buffers выставлены вменяемо -- а косты сколько поставлены?
По поводу дисков -- не уверен, возможно и ssd, random_page_cost -- дефолтный, т.е. 4, косты в дефолте, shared_buffers = 64GB
Так вы проверьте -- что вам про диски-то обещают. И да, косты -- поставьте хотя бы из http://pgconfigurator.cybertec.at/
про диски не могу найти: там аппаратный рейд от адаптека, по управления не стоит...
random_page_cost не связан непосредственно с дисками; более того, среди других настроек это наименее важный параметр. См. https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server Если уж заниматься tuning — стоит начинать с конфигурирования OS, см. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT (начиная с этого пункта, по крайней мере). А если Вы сейчас существенно измените настройки, то производительность базы может так же существенно, "неузнаваемо" измениться (и, возможно, что и к худшему в каких-то важных местах).
тут уже было что-то подтюненно: vm.nr_hugepages = 33713 vm.overcommit_memory = 2
Похоже на правду. Ну а сам PostgreSQL использует huge pages, проверяли (на всякий случай)?
вроде есть: pmap $(pgrep postgres) | grep -E -- "-s- .*deleted" | sort -u 00002aaaaac00000 68788224K rw-s- anon_hugepage (deleted)
2021-12-08 23:49:42.749 MSK [4981] LOG: duration: 49060.885 ms plan: Query Text: UPDATE t1 SET time = now() WHERE ctid = ANY(ARRAY( SELECT t1.ctid FROM t1, (SELECT name, ip FROM t2) AS tmp WHERE t1.name = tmp.name AND t1.ip = tmp.ip ORDER BY t1.name, t1.ip FOR UPDATE)) Update on t1 (cost=554418.03..554458.16 rows=10 width=36) (actual time=49060.859..49060.882 rows=0 loops=1) Buffers: shared hit=5477394 read=1 dirtied=107813, local hit=181689 read=787022 dirtied=787022 written=787021, temp read=63986 written=64010 InitPlan 1 (returns $1) -> LockRows (cost=554348.76..554418.02 rows=5541 width=32) (actual time=6836.495..27580.167 rows=963299 loops=1) Buffers: shared hit=2074078 dirtied=63181, local hit=181689 read=787022 dirtied=787022 written=787021, temp read=63986 written=64010 -> Sort (cost=554348.76..554362.61 rows=5541 width=32) (actual time=6836.420..7131.890 rows=963299 loops=1) Sort Key: t1_1.name, t1_1.ip Sort Method: external merge Disk: 42136kB Buffers: shared hit=155111, local read=5412 dirtied=5412 written=5411, temp read=63986 written=64010 -> Hash Join (cost=28636.10..554004.22 rows=5541 width=32) (actual time=391.084..6322.387 rows=963299 loops=1) Hash Cond: ((t1_1.name = t2.name) AND (t1_1.ip = t2.ip)) Buffers: shared hit=155111, local read=5412 dirtied=5412 written=5411, temp read=56385 written=56385 -> Seq Scan on t1 t1_1 (cost=0.00..290161.57 rows=13505057 width=20) (actual time=0.006..1569.288 rows=10750328 loops=1) Buffers: shared hit=155111 -> Hash (cost=12285.24..12285.24 rows=687324 width=42) (actual time=360.583..360.586 rows=963299 loops=1) Buckets: 65536 Batches: 16 Memory Usage: 3674kB Buffers: local read=5412 dirtied=5412 written=5411, temp written=4582 -> Seq Scan on t2 (cost=0.00..12285.24 rows=687324 width=42) (actual time=0.025..157.180 rows=963299 loops=1) Buffers: local read=5412 dirtied=5412 written=5411 -> Tid Scan on t1 (cost=0.01..40.14 rows=10 width=36) (actual time=27934.451..28277.042 rows=963299 loops=1) TID Cond: (ctid = ANY ($1)) Buffers: shared hit=3037377 dirtied=63181, local hit=181689 read=787022 dirtied=787022 written=787021, temp read=63986 written=64010 такое чувство, что ничего не поменялось...
Видимо, куда-то не туда вставил. Поскольку seq scan на t1 при enable_seqscan = off ни почём бы не было. Слушай, ты, главное, свою t2 в сторону сохранил?
пытался, но не сохранилась, не понимаю, почему....
Вероятно, потому жэ, почему seqscan не включилась -- запусукался старый код.
т.е. мой код оно увидело, а таблицу не создало, в логах ругань на новый код: https://t.me/pgsql/346820
Ну, ок. Видимо, не в том месте скрипта поставил.
Обсуждают сегодня