VY
создал индекс, скорость существенно увеличилась, спасибо
EXPLAIN (analyze, buffers) запроса покажите, пжлстSize: a a a
2020 July 31
YS
создал индекс, скорость существенно увеличилась, спасибо
А покажите получившийся EXPLAIN (ANALYZE, BUFFERS) — интересно, что получилось-то.
НК
Limit (cost=206251.90..206252.84 rows=8 width=1034) (actual time=988.810..993.348 rows=8 loops=1)
Buffers: shared hit=151 read=196142
-> Gather Merge (cost=206251.90..260979.16 rows=469058 width=1034) (actual time=988.807..993.339 rows=8 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=151 read=196142
-> Sort (cost=205251.88..205838.20 rows=234529 width=1034) (actual time=978.541..978.542 rows=6 loops=3)
Sort Key: torg.published_at DESC
Sort Method: top-N heapsort Memory: 48kB
Worker 0: Sort Method: top-N heapsort Memory: 39kB
Worker 1: Sort Method: top-N heapsort Memory: 33kB
Buffers: shared hit=151 read=196142
-> Parallel Hash Left Join (cost=6874.35..200561.30 rows=234529 width=1034) (actual time=77.966..870.022 rows=187623 loops=3)
Hash Cond: (lot.torg_id = torg.id)
Buffers: shared hit=93 read=196142
-> Parallel Seq Scan on lot (cost=0.00..193071.29 rows=234529 width=1026) (actual time=0.051..676.797 rows=187623 loops=3)
Buffers: shared hit=1 read=190725
-> Parallel Hash (cost=6065.82..6065.82 rows=64682 width=16) (actual time=74.303..74.304 rows=51746 loops=3)
Buckets: 262144 Batches: 1 Memory Usage: 9376kB
Buffers: shared hit=2 read=5417
-> Parallel Seq Scan on torg (cost=0.00..6065.82 rows=64682 width=16) (actual time=0.109..50.274 rows=51746 loops=3)
Buffers: shared hit=2 read=5417
Planning Time: 1.702 ms
Execution Time: 993.643 ms
VY
а ничего не поменялось…
VY
вероятно разогрели кэш ОС, вот и стало быстрее
YS
Limit (cost=206251.90..206252.84 rows=8 width=1034) (actual time=988.810..993.348 rows=8 loops=1)
Buffers: shared hit=151 read=196142
-> Gather Merge (cost=206251.90..260979.16 rows=469058 width=1034) (actual time=988.807..993.339 rows=8 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=151 read=196142
-> Sort (cost=205251.88..205838.20 rows=234529 width=1034) (actual time=978.541..978.542 rows=6 loops=3)
Sort Key: torg.published_at DESC
Sort Method: top-N heapsort Memory: 48kB
Worker 0: Sort Method: top-N heapsort Memory: 39kB
Worker 1: Sort Method: top-N heapsort Memory: 33kB
Buffers: shared hit=151 read=196142
-> Parallel Hash Left Join (cost=6874.35..200561.30 rows=234529 width=1034) (actual time=77.966..870.022 rows=187623 loops=3)
Hash Cond: (lot.torg_id = torg.id)
Buffers: shared hit=93 read=196142
-> Parallel Seq Scan on lot (cost=0.00..193071.29 rows=234529 width=1026) (actual time=0.051..676.797 rows=187623 loops=3)
Buffers: shared hit=1 read=190725
-> Parallel Hash (cost=6065.82..6065.82 rows=64682 width=16) (actual time=74.303..74.304 rows=51746 loops=3)
Buckets: 262144 Batches: 1 Memory Usage: 9376kB
Buffers: shared hit=2 read=5417
-> Parallel Seq Scan on torg (cost=0.00..6065.82 rows=64682 width=16) (actual time=0.109..50.274 rows=51746 loops=3)
Buffers: shared hit=2 read=5417
Planning Time: 1.702 ms
Execution Time: 993.643 ms
Это то же самое, индекс Вам не помог.
НК
ага, понятно
НК
а если так
Limit (cost=0.84..14.17 rows=8 width=1034) (actual time=0.064..0.096 rows=8 loops=1)
Buffers: shared hit=17
-> Nested Loop (cost=0.84..937194.76 rows=562870 width=1034) (actual time=0.062..0.092 rows=8 loops=1)
Buffers: shared hit=17
-> Index Scan using "idx-torg-published_at-desc" on torg (cost=0.42..25288.72 rows=155237 width=16) (actual time=0.035..0.037 rows=3 loops=1)
Buffers: shared hit=5
-> Index Scan using "idx-torg_id" on lot (cost=0.42..5.69 rows=18 width=1026) (actual time=0.012..0.013 rows=3 loops=3)
Index Cond: (torg_id = torg.id)
Buffers: shared hit=12
Planning Time: 0.362 ms
Execution Time: 0.139 ms
YS
а как можно было бы переписать? с саб запросом? можно просто наводку
А можете \d каждой таблицы показать (мне кажется, я не совсем понял цель запроса, всё же... lot.torg_id — NULL-able, получается)?
YS
а если так
Limit (cost=0.84..14.17 rows=8 width=1034) (actual time=0.064..0.096 rows=8 loops=1)
Buffers: shared hit=17
-> Nested Loop (cost=0.84..937194.76 rows=562870 width=1034) (actual time=0.062..0.092 rows=8 loops=1)
Buffers: shared hit=17
-> Index Scan using "idx-torg-published_at-desc" on torg (cost=0.42..25288.72 rows=155237 width=16) (actual time=0.035..0.037 rows=3 loops=1)
Buffers: shared hit=5
-> Index Scan using "idx-torg_id" on lot (cost=0.42..5.69 rows=18 width=1026) (actual time=0.012..0.013 rows=3 loops=3)
Index Cond: (torg_id = torg.id)
Buffers: shared hit=12
Planning Time: 0.362 ms
Execution Time: 0.139 ms
Так это inner join.
2020 August 01
НК
Yaroslav Schekin
А можете \d каждой таблицы показать (мне кажется, я не совсем понял цель запроса, всё же... lot.torg_id — NULL-able, получается)?
не, создан FK на torg,id
VY
не, создан FK на torg,id
наличие FK не значит, что там не может быть NULL, только если колонка имеет
и в таком случае LEFT JOIN не нужен
NOT NULL признак.и в таком случае LEFT JOIN не нужен
YS
не, создан FK на torg,id
Так если это поле не NULL-able, и есть FK — зачем вообще LEFT JOIN?
НК
да, верно, left join не нужен, спасибо
M
Запрос простейший, даже если миллиарды записей, выборка должна быть меньше секунды, так как индекс должен все решать. Вопрос к знатокам, почему планировщик не использует этот индекс, а должен же?
M
Ну только наверно джойнил бы я тут наоборот, к торгам их лоты, а не торги к лотам. Но разницы нет.
ВС
@gsmolk почему не мержит инкременты ? --retention-window=1 --retention-redundancy=1 а бэкапов 2 дня
GS
потому что redundancy=1
GS
надо только window оставить
ВС
надо только window оставить
ок момент попробую