Contexte et objectifs

Le projet Qwen explore la capacité d’un modèle de langage de 4 milliards de paramètres à surpasser l’optimiseur natif de PostgreSQL. L’objectif principal était de réduire le temps d’exécution des requêtes de jointure, un problème classé NP‑hard, en apprenant à proposer des plans plus rapides que ceux générés par défaut. L’étude s’appuie sur deux benchmarks classiques : le Join Order Benchmark et le Cardinality Estimation Benchmark, afin de mesurer les gains sur des charges de travail réalistes.

Méthodologie d’entraînement

Le modèle a d’abord été affiné par supervised fine‑tuning (SFT) à partir d’un jeu de trajectoires d’agents GPT‑6 Astra, puis soumis à un apprentissage par renforcement agentique. Chaque requête déclenche quatre rollouts ; Qwen génère un plan candidat par rollout, qui est exécuté dans un conteneur PostgreSQL dédié. Le temps d’exécution mesuré sert de récompense scalaire, propagée pour ajuster les poids du modèle. Un variant GRPO a été conçu pour stabiliser les scores dans cet environnement bruyant, et les rollouts ont été répartis entre une machine vLLM et un serveur d’entraînement équipé de deux GPU H100.

Pour minimiser le bruit lié à la contention du cache Linux, un rig de mesure a été mis en place avec quatre instances PostgreSQL isolées, chacune exécutant les plans dans des conteneurs distincts. Le processus d’off‑policy distillation a ensuite été appliqué sur environ 500 trajectoires d’agents, permettant de transférer les politiques apprises vers le modèle de 4 B sans perte de performance.

Résultats et analyse

Sur un jeu de 113 requêtes lourdes en jointures, le modèle a atteint une réduction moyenne de latence de 44,7 %, avec un pic de 81 % d’accélération sur certaines requêtes. Initialement, le modèle ne pouvait générer un plan que pour 14 % des requêtes (14/113) ; après entraînement, il a produit des plans valides pour 99 % d’entre elles, ne laissant que 1 requête sans plan exploitable. Le gain de vitesse a été évalué à l’aide du geometric mean speedup et du total workload speedup, confirmant une amélioration globale du temps de traitement du workload complet.

Les gains proviennent principalement d’une meilleure estimation de cardinalité grâce à Low‑Rank Adaptation (LoRA), qui affine les représentations internes du modèle sans augmenter le nombre de paramètres. Le modèle apprend également à privilégier des stratégies de jointure telles que HashJoin ou Leading lorsqu’elles offrent un coût moindre, comme illustré dans l’exemple SQL suivant :

SELECT cn.name, COUNT(*) AS titles
FROM title t
JOIN movie_companies mc ON mc.movie_id = t.id
JOIN company_name cn ON cn.id = mc.company_id
WHERE cn.country_code = 'jp'
  AND t.production_year BETWEEN 2000 AND 2009
GROUP BY cn.name
ORDER BY titles DESC
LIMIT 10;

Limites et perspectives

Malgré les performances affichées, le système reste sensible aux variations du cache et aux différences de configuration matérielle, ce qui impose une calibration fine du rig de mesure. De plus, le modèle a été entraîné sur un seul type de workload (jointures lourdes) ; son efficacité sur des requêtes à forte composante d’agrégation ou de filtrage reste à tester. Les travaux futurs prévoient d’étendre l’entraînement à d’autres SGBD, d’intégrer des métriques de coût multi‑objectifs (mémoire, I/O) et d’explorer des architectures de modèle plus compactes pour un déploiement en production.