Files
document-haness/docs/n+1liner/final/evidence/raw/explain/l16-union-branches.txt
T

21 lines
1.4 KiB
Plaintext
Executable File

-- L16 union branches — each visibility branch rides its own optimal plan (what single-OR can't)
-- FeedVisibilityIT.l16LowSelectivityBranchesRideTheirIndex (seed 2000, viewer user008)
-- 읽기 포인트: 저선택도 분기는 자기 인덱스를 탄다 — mentioned=ix_mentions_user 조인, private=ix_feed_items_private
-- partial 의 Index Only Scan. public(60% 고선택도)은 Bitmap Heap Scan+top-N Sort 가 최적.
-- 단일 OR 은 3분기를 하나의 bitmap 으로 묶어 분기별 최적 플랜을 못 가진다.
== mentioned branch (JOIN feed_item_mentions on ix_mentions_user) ==
Limit -> Sort (top-N) -> Hash Join (fi.id = m.feed_item_id)
-> Bitmap Heap Scan on feed_items fi (visibility='MENTIONED')
-> Hash -> Bitmap Heap Scan on feed_item_mentions m
-> Bitmap Index Scan on ix_mentions_user (Index Cond: mentioned_user_id = :me) rows=200
== private branch (partial index ix_feed_items_private WHERE visibility='PRIVATE') ==
Limit -> Incremental Sort (Presorted Key: first_highlighted_at)
-> Index Only Scan using ix_feed_items_private on feed_items fi (Index Cond: user_id = :me) Heap Fetches: 21
== public branch (60% selectivity -> seq/bitmap + top-N is optimal, not an index range) ==
Limit -> Sort (top-N heapsort)
-> Bitmap Heap Scan on feed_items fi (Recheck Cond: visibility='PUBLIC')
-> Bitmap Index Scan on ix_feed_items_visibility_sort (Index Cond: visibility='PUBLIC')