반복되는 Page ToOne 부모 쿼리의 실행계획 (N2 — 선형 범인)
출처: FeedPersistenceIT.l2ExplainRepeatedPageToOneQuery 콘솔 출력
조건: seed(100) 직후. warm buffer cache(shared read=0). id는 시드된 실제 pages.id 1건.
쿼리: SELECT * FROM pages WHERE id = ?   (@ManyToOne EAGER가 행마다 반복하는 2차 SELECT)

Index Scan using pk_pages on pages
  (cost=0.14..8.15 rows=1 width=2104) (actual time=0.009..0.009 rows=1 loops=1)
  Index Cond: (id = 'a069f5ac-fa46-41f8-bcde-174153789467'::uuid)
  Buffers: shared hit=2
Planning Time: 0.031 ms
Execution Time: 0.021 ms

주의(문서 §7.3 / §6.4 caveat와 동일):
- PK 조회라 pk_pages Index Scan으로 1건 0.021 ms. "쿼리가 느려서"가 아니다 — page는 아이템당
  고유(dedup 없음)라 이 빠른 계획이 정확히 N번 반복되는 게 문제다(왕복 N회).
- users 계획(toone-users-plan.txt)과 실행계획이 사실상 동일하다. 비용을 가르는 것은 계획이 아니라
  반복 횟수(page=N vs user=distinct≤20)다 — 카디널리티가 곡선을 가른다.
- Buffers: shared hit=2, read=0 → warm buffer cache. cold 디스크 I/O 실행시간으로 읽지 말 것.
- Execution Time 0.021 ms는 executor 내부 시간. 애플리케이션 지연(§6.2)과 같은 지표가 아니다.
- 인덱스로 안 풀린다(계획이 이미 PK Index Scan). 왕복 횟수 자체를 줄이는 fetch 전략이 필요(§9).
