엔티티만 페이징한 SQL의 실행계획 (a) — Limit 노드 존재 (배치 페치 해법의 페이징)
출처: FeedBatchFetchIT.l5ExplainEntityPagingHasLimitAndBatchInHasNoRowMultiplication 콘솔 출력 (a)
조건: seed(100) 직후, default_batch_fetch_size=100 세션. warm buffer cache.
쿼리: EXPLAIN (ANALYZE, BUFFERS)
      SELECT fi.* FROM feed_items fi ORDER BY fi.first_highlighted_at DESC, fi.id ASC LIMIT 20
      (배치 해법은 fetch join을 버리고 엔티티만 페이징한다 → DB가 정상 페이징)

Limit  (cost=71.96..72.01 rows=20 width=1194) (actual time=0.108..0.109 rows=20 loops=1)
  Buffers: shared hit=65
  ->  Sort  (cost=71.96..72.84 rows=354 width=1194) (actual time=0.107..0.108 rows=20 loops=1)
        Sort Key: first_highlighted_at DESC, id
        Sort Method: top-N heapsort  Memory: 28kB
        Buffers: shared hit=65
        ->  Seq Scan on feed_items fi  (cost=0.00..62.54 rows=354 width=1194) (actual time=0.075..0.080 rows=100 loops=1)
              Buffers: shared hit=59
Planning:
  Buffers: shared hit=14 read=1
Planning Time: 0.085 ms
Execution Time: 0.118 ms

관찰(문서 §11):
- 계획 최상단에 Limit 노드가 있다 = DB가 페이징을 했다. top-N heapsort 28kB로 상위 20행만 취한다.
- L4 (a)(컬렉션 fetch join)는 Limit 노드가 없어 전체 1961행을 quicksort(445kB)로 정렬했다 — 정반대.
  fetch join을 버리니(엔티티만 페이징) 페이징이 DB로 내려간다(HHH000104 인메모리 페이징 소멸).
- 대조군: l5-batch-in-semijoin.txt (페이지 부모들의 highlights 를 IN 한 방으로 — 행을 곱하지 않는다).
- Buffers: read≈0 → warm buffer cache. Execution Time 0.118 ms 는 executor 내부 시간(§6.4 caveat와 동일).
