نموذج بحجم 4B يُدرَّب على إنتاج خطط استعلام لـ Postgres أسرع بنسبة 44.7% في الزمن
خطة التنفيذ التي يختارها محرك قاعدة البيانات ليست الخطة المثلى، بل أفضل تخمين من إحصائيات قديمة، وهذا التخمين يمكن تصحيحه بالتجربة.
نشر Rohan Bansal يوم 16 سبتمبر 2026 مقالًا يصف تدريب نموذج Qwen بحجم 4B على إنتاج خطط تنفيذ لاستعلامات Postgres. والنتيجة بحسب الكاتب: خفض زمن التنفيذ بنسبة 44.7% على 113 استعلامًا كثيف الـ joins من مجموعة بيانات IMDb، أي أسرع بنحو 81%.
والمفارقة أن النموذج نفسه كان في البداية عاجزًا عن إنتاج خطة أصلًا لـ 99 من هذه الاستعلامات الـ 113. وقد دُرّب بمرحلتين: SFT أولًا، ثم agentic reinforcement learning بنسخة معدلة من خوارزمية GRPO.
لماذا يمكن التفوق على المحرك
ترتيب الـ joins، أي البدء بجدول قبل آخر، مسألة NP-hard، ولا يحلها أي محرك حلًا دقيقًا. كل المحركات تخمّن. والـ optimizer في Postgres يخمّن اعتمادًا على إحصائيات مخزنة عن الجداول، ويبتعد تخمينه عن الواقع كلما كبر الاستعلام وكثرت فيه الـ joins.
لكن تصحيح هذا التخمين سهل نسبيًا. فلا حاجة لمعرفة الخطة الصحيحة مسبقًا، يكفي تشغيل خطتين ومعرفة أيهما انتهى أولًا. وهذا بالضبط شكل المسائل التي ينجح فيها الـ reinforcement learning: مكافأة واحدة واضحة وقابلة للقياس، هي زمن التنفيذ.
والعمل تجربة بحثية فردية، لا أداة جاهزة لبيئة الإنتاج.
غير أنه يغيّر طريقة قراءة مخرجات EXPLAIN، الأمر الذي يعرض الخطة التي اختارها المحرك. فالخطة التي تنفّذ استعلامات أي API اليوم ليست بالضرورة المثلى، بل هي أفضل ما استطاع المحرك تقديره بالإحصائيات المتاحة له لحظة التخطيط.