refactor: 분리되어 관리하고 있던 문서 시스템을 하나로 통일

2026-09-04 18:56:01 +09:00
parent 4b9e7148b5
commit 43bccd08a8
121 changed files with 2861 additions and 534 deletions
@@ -0,0 +1,20 @@
+반복되는 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).