LATERAL 조인: 성능 기능이 아니라 스코프 규칙이다
LATERAL이 FROM 절의 스코프를 여는 문법 규칙이라는 정의에서 출발해, 그것이 강제하는 Nested Loop 실행 모양과 비용 모델, 그룹별 상위 N건 같은 고유 용도, 그리고 de-correlate 리라이팅까지 정리한다.
키워드가 정확히 일치하지 않아도 의미로 글을 찾아줍니다. 모든 처리는 브라우저 안에서 일어나며 — 서버·API 키·외부 전송이 없습니다. (검색 모델은 처음 한 번만 받고 이후 캐시됩니다.)
매일 자동으로 바뀌는 복습 6선 — Network · OS · Algorithm · Database 각 1편 + 랜덤 2편.
LATERAL이 FROM 절의 스코프를 여는 문법 규칙이라는 정의에서 출발해, 그것이 강제하는 Nested Loop 실행 모양과 비용 모델, 그룹별 상위 N건 같은 고유 용도, 그리고 de-correlate 리라이팅까지 정리한다.
from+size가 샤드마다 from+size를 힙에 쌓는 구조와 max_result_window 제한의 근거, search_after·PIT·scroll의 선택 기준, 그리고 UI 결정이 곧 아키텍처 결정인 이유.
filter 컨텍스트에서 boost가 무시되는 이유, boost가 절대 점수가 아니라 곱셈 계수인 탓에 우선순위 계단이 뒤집히는 구조, 그리고 dis_max와 constant_score로 계단을 보장하는 법.
와일드카드가 AutomatonQuery로 컴파일되어 term dictionary와 교차하는 과정, 선행 와일드카드가 전수 스캔이 되는 이유, 그리고 색인 시점으로 비용을 옮기는 세 가지 처방.
검색엔진 분리를 성능이 아니라 질의 표현력으로 판단하는 기준과, 분리하면서 실제로 잃게 되는 일곱 가지를 증상 단위로 정리한다.
계획의 한 줄이 실제로는 디스크와 메모리에서 무슨 일인지 — 8KB 페이지, 저장 계층의 지연 시간, shared_buffers와 work_mem의 역할 분담, 노드별 메모리 사용과 초과 시 동작을 정리한다.
실행계획을 트리로 읽는 순서, 노드 한 줄의 문법, cost와 actual의 의미, 숫자마다 다른 단위, 스캔·조인 노드의 종류와 선택 기준을 정리한 레퍼런스.

같은 조회를 매번 DB까지 가는 게 아까울 때 자주 바뀌지 않는데 조회는 많은 데이터(카테고리 목록, 환율, 사용자 권한)는 매번 DB를 때리는 게 낭비입니다. Spring의 캐시 추상화를 쓰면 저장소(로컬 맵, Caffeine, Redis…)가 무엇이든 애너테이션만으로 캐싱을 얹을 수 있습니다. 문제는 이 추상화를 “애너테이션 붙이면 빨라지는 마...

의존성만 추가했는데 갑자기 로그인 창이 뜬다 spring-boot-starter-security를 추가하면, 아무 설정도 안 했는데 모든 요청에 로그인 창이 뜹니다. 이건 Spring Security의 “기본적으로 다 막는다(secure by default)” 철학입니다. 그런데 이걸 “로그인 창 = 보안”으로만 이해하면, 막상 @PreAuthori...