Files
document-haness/docs/n+1liner/final/evidence/raw/explain/l14-lateral-no-index.txt
T

30 lines
2.0 KiB
Plaintext
Executable File

-- L14 index toggle — the SAME LATERAL query with ix_highlights_feed_items_created DROPPED
-- FeedTopNIT.l14LateralDependsOnCompositeIndex (seed 1000, page 20, K=3; index dropped then restored)
-- 읽기 포인트: 인덱스가 없으면 부모마다 highlights 를 Seq Scan 하고(Rows Removed by Filter: 2842/loop)
-- top-N heapsort 로 3개를 고른다 → child 쪽 buffers shared hit=4340, 전체 4446 (인덱스판 168 의 ~26배),
-- Execution 5.472 ms (인덱스판 0.336 ms 의 ~16배). 결론: LATERAL 이 빠른 건 LATERAL 이 아니라
-- (feed_item_id, created_at DESC) 인덱스 seek 덕. 인덱스가 없으면 LATERAL 도 무너진다.
Nested Loop (cost=376.28..5070.14 rows=60 width=686) (actual time=0.599..5.451 rows=60 loops=1)
Buffers: shared hit=4446
-> Limit (cost=129.28..129.33 rows=20 width=24) (actual time=0.218..0.221 rows=20 loops=1)
Buffers: shared hit=106
-> Sort (cost=129.28..130.87 rows=636 width=24) (actual time=0.218..0.219 rows=20 loops=1)
Sort Key: fi.first_highlighted_at DESC, fi.id
Sort Method: top-N heapsort Memory: 26kB
Buffers: shared hit=106
-> Seq Scan on feed_items fi (cost=0.00..112.36 rows=636 width=24) (actual time=0.086..0.150 rows=1000 loops=1)
Buffers: shared hit=106
-> Limit (cost=246.99..247.00 rows=3 width=670) (actual time=0.261..0.261 rows=3 loops=20)
Buffers: shared hit=4340
-> Sort (cost=246.99..247.02 rows=12 width=670) (actual time=0.259..0.259 rows=3 loops=20)
Sort Key: h.created_at DESC
Sort Method: top-N heapsort Memory: 25kB
Buffers: shared hit=4340
-> Seq Scan on highlights h (cost=0.00..246.84 rows=12 width=670) (actual time=0.171..0.249 rows=75 loops=20)
Filter: (feed_item_id = fi.id)
Rows Removed by Filter: 2842
Buffers: shared hit=4340
Planning Time: 0.079 ms
Execution Time: 5.472 ms