-- 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