Suppression de Protobuf et amélioration des performances par 5 grâce à des liaisons directes Rust↔C

• PgDog, un proxy d’extension pour PostgreSQL, a introduit des liaisons directes Rust au lieu de la sérialisation Protobuf afin d’améliorer les performances de parsing SQL
• L’ancienne architecture basée sur Protobuf a été remplacée par une conversion directe C–Rust (bindgen + wrappers générés par Claude), avec à la clé des performances 5,45× supérieures en parsing et 9,64× en déparsing
• Le goulot d’étranglement de performance a été identifié dans la fonction pg_query_parse_protobuf ; après des tentatives de mise en cache, l’équipe a procédé à un changement structurel pour obtenir un gain durable
• En utilisant le LLM Claude, l’équipe a généré automatiquement 6 000 lignes de code de conversion Rust–C et les a appliquées aux fonctions clés comme parse, deparse, fingerprint et scan
• Grâce à cette optimisation, l’utilisation CPU et la latence de PgDog ont diminué, ce qui améliore fortement son efficacité comme proxy de scalabilité horizontale pour PostgreSQL

---

PgDog et les limites de Protobuf

• PgDog est un proxy destiné à faire monter PostgreSQL en charge, et utilise en interne libpg_query pour parser les requêtes SQL
  • Écrit en Rust, il communiquait auparavant avec la bibliothèque C via la sérialisation/désérialisation Protobuf
• Protobuf est rapide, mais les liaisons directes le sont davantage
  • L’équipe de PgDog a forké pg_query.rs pour supprimer Protobuf et implémenter des liaisons directes C–Rust
  • Résultat : le parsing des requêtes est devenu 5,45 fois plus rapide, et le déparsing 9,64 fois plus rapide

Résultats des benchmarks

• Les benchmarks peuvent être reproduits dans le dépôt forké de PgDog
  • pg_query::parse (Protobuf) : 613 QPS
  • pg_query::parse_raw (C–Rust direct) : 3357 QPS
  • pg_query::deparse (Protobuf) : 759 QPS
  • pg_query::deparse_raw (Rust–C direct) : 7319 QPS

Analyse du goulot d’étranglement et tentative de cache

• L’analyse du temps CPU avec le profiler samply a montré que la fonction pg_query_parse_protobuf constituait le principal goulot d’étranglement
• Une amélioration partielle a été tentée via le cache
  • Utilisation d’un cache hashmap LRU stockant l’AST avec le texte de la requête comme clé
  • Réutilisation possible dans le cas des prepared statements
• Cependant, certains ORM généraient des milliers de requêtes uniques, et d’anciens drivers PostgreSQL ne prenaient pas en charge les prepared statements, ce qui limitait fortement l’efficacité du cache

Suppression de Protobuf à l’aide d’un LLM

• L’équipe de PgDog a utilisé le LLM Claude pour générer les liaisons Rust sans Protobuf
  • L’IA s’est montrée efficace sur une tâche au périmètre clair et vérifiable
• À partir de la spécification Protobuf de libpg_query, Claude a mappé les structures C vers des structures Rust
  • Après 2 jours d’itérations, cela a abouti à 6 000 lignes de code Rust récursif
• L’approche a été appliquée aux fonctions parse, deparse, fingerprint et scan, avec un gain de performance de 25 % selon pgbench

Détails d’implémentation

• Les conversions entre Rust et C utilisent des fonctions unsafe pour mapper directement les structures
  • Les structures C sont transmises à l’API Postgres pour générer l’AST, puis converties récursivement en Rust
• Chaque nœud de l’AST est traité par la fonction convert_node, qui mappe les centaines de tokens de la grammaire SQL
  • Des fonctions de conversion séparées existent pour chaque type de nœud, comme SELECT, INSERT, etc.
• Le résultat de conversion réutilise la structure Protobuf existante (protobuf::ParseResult), ce qui permet une validation par comparaison octet par octet lors des tests
• L’algorithme récursif est plus rapide qu’une implémentation itérative, car il effectue moins d’allocations mémoire et exploite mieux le cache CPU
  • Une implémentation itérative s’est révélée plus lente à cause d’allocations mémoire inutiles et de recherches dans une hashmap

Conclusion

• En réduisant la surcharge du parseur Postgres, PgDog diminue à la fois la latence, la mémoire et l’utilisation CPU
• Grâce à cette optimisation, PgDog devient un proxy d’extension PostgreSQL plus rapide et moins coûteux à exploiter
• PgDog recrute actuellement des ingénieurs pour construire avec lui la prochaine itération de la scalabilité horizontale de PostgreSQL