40 жилийн түүхтэй Postgres-ийн төлөвлөгчийг 4B модель буулгаж авав: Query-г 81% хурдасгасан RL туршилт

Өгөгдлийн сангийн (RDBMS) ертөнцөд хүсэлтийг хэрхэн гүйцэтгэх тухай тооцоолол буюу Query Optimization нь сүүлийн 40 гаруй жилийн турш компьютерын шинжлэх ухааны хамгийн төвөгтэй, толгой өвтгөсөн асуудлуудын нэг байсаар ирсэн. Хөгжүүлэгч бидний бичсэн ганцхан SELECT ... JOIN хүсэлтийн цаана өгөгдлийн сан хүснэгтүүдийг ямар дарааллаар унших, ямар индекс ашиглах, ямар join алгоритм (Nested Loop, Hash Join, Merge Join) сонгохыг шийдэх асар том математик комбинаторик нуугдаж байдаг.

Гэвч өнөөдөр хиймэл оюун ухааны судлаач, инженер Рохан Бансал (Rohan Bansal) ердөө 4B (4 тэрбум) параметртэй нээлттэй жижиг хэлний моделийг (SLM) дасгалжуулан, PostgreSQL-ийн олон арван жил туршигдсан алгоритмаас 81% хүртэл хурдан query plan боловсруулж чадсанаа нийтэллээ. Энэхүү туршилт нь өгөгдлийн сангуудын дараагийн эриний архитектур ямар байхыг тодорхой харуулж байна.

Асуудал: Join Ordering яагаад NP-Hard вэ?

Postgres шиг өгөгдлийн сангууд хүсэлтийг боловсруулахдаа статистик өгөгдөлд үндэслэн тухайн үйлдлийн "өртөг"-ийг (Cost estimation) урьдчилан таамаглаж, хамгийн хямд төсөр гэж үзсэн замаа (Execution Plan) сонгодог.

Гэвч холбогдох хүснэгтийн тоо нэмэгдэх тусам хайлтын орон зай (search space) экспоненциал хурдаар задардаг. Тухайлбал, ердөө 4–5 хүснэгттэй join хийхэд л гүйцэтгэх 4,600 гаруй ялгаатай хувилбар гарч ирдэг бөгөөд энэ нь онолын хувьд NP-hard бодлого юм.

Postgres нь 12 хүртэлх хүснэгтийн join дээр Dynamic Programming ашиглаж, түүнээс дээш гарвал Genetic Algorithm (GEQO) руу шилждэг. Гэвч статик хэв маяг, буруу үнэлэгдсэн статистикээс болж Postgres бодит байдал дээр оновчгүй зам сонгож, query гацах, олон минут үргэлжлэх тохиолдол байнга гардаг билээ.

Яагаад хэлний модель гэж? "Шалгахад хялбар" давуу тал

Хэлний моделиуд (LLM/SLM) сүүлийн үед код бичихдээ заримдаа хий хоосон зүйл (hallucination) зохиодгоороо шүүмжлүүлдэг. Гэвч query optimization нь өөр төрлийн бодлого юм:

Гаралтыг шууд хэмжих боломжтой (Easily Verifiable): Таамагласан төлөвлөгөөг Postgres дээр шууд ажиллуулж, хугацааг миллисекундээр нарийн хэмжиж болно. Хурдан ажиллавал "сайн", удаан ажиллавал эсвэл алдаа заавал "муу".
Тодорхой үнэлгээ (Scalar Reward): Бататгах сургалт (Reinforcement Learning - RL) хийхэд төгс тохирох орчин бөгөөд энд ямар ч хийсвэр хүний субъектив дүгнэлт хэрэггүй.

Иймээс Рохан Бансал энгийн prompt ашиглахын оронд агент чиглэлийн RL арга барилаар жижиг загварыг бие даан төлөвлөгч болгон сургахаар шийдсэн байна.

Архитектур: 2x H100 ба ширээн дээрх 4 Postgres контейнер

Туршилтын дэд бүтэц тун сонирхолтой:

Сургалтын дэд бүтэц: Rented 2x NVIDIA H100 сервер дээр vLLM болон Qwen 4B суурь загварыг байршуулсан.
Хэмжилтийн дэд бүтэц: Сургалтын дуу чимээ, сүлжээний хоцролтоос сэргийлж, инженерийн өөрийнх нь ажлын ширээн дээрх техник хангамж дээр тусгаарласан 4 ширхэг Postgres Docker контейнер зэрэг ажиллажээ.
Кэшийн саад бэрхшээл: Туршилтын үед хамгийн хүнд сорилт нь Linux Page Cache болон Shared Buffers байв. Нэг контейнер өгөгдлийг RAM-д кэшилчихвэл дараагийн төлөвлөгөө шударга бусаар хурдан уншигдах эрсдэлтэй байсан тул кэшийг зохицуулах тусгай хэмжилтийн механизм хөгжүүлсэн байна.
GRPO (Group Relative Policy Optimization): DeepSeek-ийн олонд таниулсан GRPO алгоритмын өөрчилсөн хувилбарыг ашигласан. Query бүр дээр Qwen 4B модель 4 өөр хувилбарт төлөвлөгөө (join-ийн дараалал, scan төрөл)-ийг Postgres руу илгээнэ. Postgres тэдгээрийг бодитоор ажиллуулан хугацааг хэмжиж, үндсэн дефолт төлөвлөгөөний хугацаатай харьцуулж reward онооно. Энэхүү reward нь эргээд моделийн жинг шинэчилж, загвар цаашид илүү оновчтой зам сонгох чадварт суралцдаг.

Үр дүн: 99 удаа алдаа заадаг байснаас Postgres-ийг илт давах хүртэл

Туршилтын эхэнд 4B модель нийт 113 хүнд query-ийн 99 дээр нь бүрэн зөв синтакс бүхий төлөвлөгөө ч гаргаж чадахгүй унаж байв.

Гэвч Supervised Fine-Tuning (SFT) болон олон мянган RL алхмын дараа:

Загвар хүнд join-той 113 төрлийн бодит өгөгдлийн query дээр дунджаар 44.7%-ийн latency бууруулалт хийж чадсан.
Зарим туйлын хүнд тооцоололтой хүсэлтүүд дээр Postgres-ийн 40 жилийн турш сайжруулсан Dynamic Programming алгоритмоос 81% хүртэл богино хугацаанд ажиллах төлөвлөгөөг боловсруулж өгчээ.

Хөгжүүлэгчдэд энэ юуг өгүүлж байна вэ?

Энэ нь зөвхөн нэг сонирхолтой судалгааны төсөл биш, харин дэд бүтцийн програм хангамжийн хувьсал юм:

Эвристик дүрмүүд мэдрэлийн сүлжээнд байраа тавьж өгнө: Өнөөг хүртэл өгөгдлийн сангууд хатуу дүрэм, магадлалын хялбаршуулсан таамаглал дээр тулгуурладаг байсан бол цаашид local түвшинд ажилладаг SLM тус бүрийн ачааллын хэв маягт тохируулан төлөвлөгөөгөө өөрөө сурдаг болох хаалга нээгдлээ.
Тусгай жижиг моделиудын хүч: Бүх зүйлийг аварга том 400B+ загварууд руу явуулах шаардлагагүй. Нарийн домэйнд чиглэсэн 1B–4B загварууд төхөөрөмж дээр эсвэл сервер дээр шууд ажиллаж, миллисекундийн дотор шийдвэр гаргах түвшинд хүрч байна.
Ирээдүйн Postgres: Ойрын хэдэн жилд бид postgresql.conf дээр enable_ai_planner = on гэсэн тохиргоог харж, өгөгдлийн сан дотроо локал жижиг сүлжээг ажиллуулан query-гээ оновчилдог болох нь бодит биеллээ олж эхэлснийг энэхүү туршилт нотоллоо.

Эх сурвалж: Rohan Bansal (rohanbansal.com) — "Training a 4B model to produce 81% faster query plans than Postgres", Hacker News хэлэлцүүлэг.