explain.depesz.com

A tool for finding a real cause for slow queries.

Result: IRrI

options
Did it help? Consider supporting us - Bitcoin address: 12v2hUztAk2LgzQ9H9LMwuU32urHMjZQnq
# exclusive inclusive rows x rows loops node
1. 5132.269 12805.956 ↑ 1.0 1068530 1

Sort (cost=496188.38..498859.71 rows=1068530 width=56) (actual time=11771.760..12805.956 rows=1068530 loops=1)

  • Sort Key: "_F2".title
  • Sort Method: external merge Disk: 69264kB
2. 2535.329 7673.687 ↑ 1.0 1068530 1

Hash Right Join (cost=186286.08..357885.09 rows=1068530 width=56) (actual time=4537.462..7673.687 rows=1068530 loops=1)

  • Hash Cond: (("_F2".id)::text = (hierarchy.id)::text)
3. 601.022 601.022 ↑ 1.0 1068530 1

Seq Scan on dublincore "_F2" (cost=0.00..127656.30 rows=1068530 width=55) (actual time=0.020..601.022 rows=1068530 loops=1)

4. 445.080 4537.336 ↑ 1.0 1068530 1

Hash (cost=164581.46..164581.46 rows=1068530 width=37) (actual time=4537.336..4537.336 rows=1068530 loops=1)

  • Buckets: 32768 Batches: 4 Memory Usage: 18020kB
5. 2378.031 4092.256 ↑ 1.0 1068530 1

Hash Join (cost=88841.23..164581.46 rows=1068530 width=37) (actual time=1360.663..4092.256 rows=1068530 loops=1)

  • Hash Cond: (("_F1".id)::text = (hierarchy.id)::text)
6. 353.792 353.792 ↑ 1.0 1068530 1

Seq Scan on misc "_F1" (cost=0.00..24380.62 rows=1068530 width=37) (actual time=0.014..353.792 rows=1068530 loops=1)

  • Filter: ((lifecyclestate)::text <> 'deleted'::text)
7. 841.667 1360.433 ↓ 1.2 2086864 1

Hash (cost=54280.88..54280.88 rows=1701388 width=37) (actual time=1360.433..1360.433 rows=2086864 loops=1)

  • Buckets: 32768 Batches: 8 Memory Usage: 17613kB
8. 518.766 518.766 ↓ 1.2 2086864 1

Seq Scan on hierarchy (cost=0.00..54280.88 rows=1701388 width=37) (actual time=0.007..518.766 rows=2086864 loops=1)