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,26 @@
+엔티티만 페이징한 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와 동일).