Postgres보다 81% 빠른 실행 계획이라지만, 데이터셋은 메모리에 전부 들어가는 8GB이고 shared_buffers는 그 일부로 제한했으며, 측정 전에 쿼리를 워밍업했고 읽기 전용 SELECT만 사용함. 과적합을 경계해야 함. 규모가 커지고 더 현실적인 OLTP 부하가 주어져도 Postgres의 휴리스틱보다 나은 실행 계획을 만들지는 판단하기 어려움. 프로파일 기반 최적화가 늘 그렇듯, 데이터베이스 부하는 시간과 규모에 따라 달라질 수 있음. 그래도 직접 실험하고 결과를 정리한 점은 높이 평가함.

최적 실행 계획 생성은 수학과 알고리즘의 비중이 크고, 작업 부하에 따라서도 달라짐. 필요할 때 즉석에서 인덱스를 만드는 선택지까지 고려하면 탐색 공간은 글에서 제시한 것보다 더 빠르게 커짐. 전체 실행 시간에서 쿼리 계획 수립 자체가 병목인 경우도 있음.
여기에 LLM을 쓰는 건 다소 투박한 접근임. 오히려 AlphaGo 방식의 신경망 휴리스틱을 기다리고 있음.

“Astra의 실행 궤적을 증류한 결과만 봐도 최첨단 대형 모델은 앞으로도 필요하다”라고 인정하면, 폐쇄형·개방형 모델 사이에서 증류 논란이 오가는 상황에 문제를 자초하는 것 아닐까?

반대로 대형 최첨단 모델 업체들이 법원에 증류가 나쁘다는 논리를 관철했을 때, 우리가 얼마나 많은 것을 포기하게 될지 아는 것도 중요함.

최첨단 모델 개발사들은 학습 데이터 대부분을 훔쳤음. 저작권이 있는 인터넷 전체를 가져다 쓴 셈이라 도덕적 우위를 내세우기 어려움. 대영제국에서 사과 하나 훔치는 것과 비슷함.

소형 모델이 증류를 한다는 사실 자체를 부정하는 건 아니라고 봄. 현재 쟁점은 최첨단 모델 연구소끼리 대형 모델을 증류하는 문제임.

Lambda에서 H100 SXM 2개짜리 노드를 약 95시간 빌리는 데 약 800달러, Astra 시연 궤적을 생성하는 OpenAI API에 약 400달러를 썼다고 함. 그렇게 4B 모델이 조인 위주 SQL 부하에서 기하평균 1.81배 속도 향상과 총 지연 시간 44.7% 감소를 달성했지만, 95시간의 학습 비용은 벤치마크 수치에 포함하지 않은 듯함. 글을 너무 훑어봤는지 해당 설명은 찾지 못함.
실행 계획 도출에 충분한 시간을 쓸 수 있다면 최적화 성능이 훨씬 좋아진다는 건 데이터베이스 업체들도 알 것임. 일부 부하에는 유용하겠지만, 좋은 실행 계획을 유지하려고 주기적으로 몇 시간씩 모델을 갱신할 여유가 있을까?

예약 백업과 비슷하게 보면 허용할 만한 유지보수 시간일 수 있음. 다만 모델 재학습이나 추가 미세조정보다 결정론적 알고리즘이 더 나을 가능성이 큼. 예를 들어 데이터가 균등하게 분포한다고 가정하는 대신 실제 분포를 분석하면 일부 실행 계획은 자동으로 배제할 수 있음.
컴파일러처럼 극도로 최적화된 분야를 생각해 보면 좋겠음. 수십 년간 정교하게 다듬은 소프트웨어에 LLM이 구조나 성능 면에서 뭔가를 더할 수 있을까? 나는 아니라고 봄.

어제 올라온 Jev 모델을 보고 마침 아주 비슷한 접근을 생각하고 있었음.

최적화는 결정론적이어야 하는 것 아닌가?

MSSQL 관리와 개발을 해본 정도의 아마추어 관점이지만, 통계 기반 최적화에서는 통계 자체가 변수라 실행 계획이 갑자기 바뀔 수 있음.
쿼리는 통계에 따라 실행 계획으로 변환되지만, 변환 자체는 결정론적이며 유효한 계획을 다른 유효한 계획으로 바꿔야 함. 신경망도 기존 코드처럼 이 변환들을 선택할 수 있다고 봄. 웹 문서가 아니라 수많은 자기 대국으로 국면 평가를 학습하는 체스 엔진처럼, 닫힌 환경에서의 학습이 잘 맞을 수 있음.
데이터의 통계나 카디널리티 패턴을 보고 어떤 유효한 실행 계획 변환을 적용할지 학습하는 방식임. 어디까지나 가설이니 틀린 부분은 고쳐주면 좋겠음!

그렇지는 않음. 여러 실행 계획 중 무엇을 고를지는 데이터의 요약 통계에 달려 있으며, 그 통계가 최신이 아닐 수도 있음.

실행 계획이 쿼리가 요구한 일을 실제로 수행하는지는 어떻게 알 수 있을까?

pg_hint_plan 이 받아들이는 모든 힌트가 해당 쿼리에 유효한 실행 계획만 만들도록 설계됐으리라 기대함. 이런 성질을 보장하면서도 좋은 실행 계획을 표현하는 체계는 가능하며, 지나치게 복잡하지도 않을 것이라고 확신함.
그렇다고 임의의 알고리즘이 원하는 일을 하는지 일반적으로 검증할 수 있다는 뜻은 아님. 질문을 어떻게 정식화하느냐에 따라 결정 불가능하거나 NP-난해 또는 co-NP-난해할 수 있음.

pg_hint_plan의 디버그 로그로 Postgres가 실제로 힌트를 사용했는지 확인할 수 있음! 평가할 때 이 기능을 사용했음.

실행 계획에 변환 연산을 적용하면서 동치 여부를 판정할 수 있지 않을까?

Lean4 코드로 동치성을 증명하거나, 쿼리 절 트리를 비교해야 할지도 모르겠음.

P≠NP일 가능성이 매우 높다고 보는데, 생성은 비싸고 휴리스틱에 의존하지만 검증은 상대적으로 저렴한 문제가 아주 많음. 이런 문제에서는 생성 단계에 LLM을 유용하게 쓸 수 있음.

글이 왜 이렇게 긴 걸까? 다 읽는 데만 5일은 걸리겠음.

논문처럼 읽으면 됨. 논문에 왜 이렇게 기냐고 묻지는 않을 것임. 이제는 AI에 요약을 맡기고, 관심 있는 부분만 골라 질문할 수도 있음.