Protobuf हटाकर Rust↔C direct binding से प्रदर्शन 5 गुना बेहतर

• PostgreSQL extension proxy PgDog ने SQL parsing performance बढ़ाने के लिए Protobuf serialization की जगह Rust direct binding अपनाई
• मौजूदा Protobuf-आधारित संरचना को C–Rust direct conversion (bindgen + Claude द्वारा जनरेटेड wrapper) से बदलकर parsing 5.45 गुना, deparsing 9.64 गुना तेज किया गया
• performance bottleneck pg_query_parse_protobuf फ़ंक्शन में मिला, और caching की कोशिशों के बाद भी मूलभूत सुधार के लिए संरचना बदली गई
• Claude LLM का उपयोग करके 6,000 lines का Rust–C conversion code अपने-आप जनरेट किया गया, और इसे parse, deparse, fingerprint, scan जैसी मुख्य functions पर लागू किया गया
• इस optimization से PgDog की CPU usage और latency घटी, और PostgreSQL horizontal scaling proxy के रूप में इसकी efficiency काफ़ी बढ़ी

---

PgDog और Protobuf की सीमाएँ

• PgDog PostgreSQL को scale करने के लिए बना एक proxy है, जो अंदरूनी तौर पर SQL queries parse करने के लिए libpg_query का उपयोग करता है
  • यह Rust में लिखा गया है, और पहले Protobuf serialization/deserialization के ज़रिए C library से communicate करता था
• Protobuf तेज़ है, लेकिन direct binding तरीका उससे भी तेज़ है
  • PgDog टीम ने pg_query.rs को fork करके Protobuf हटाया और C–Rust direct binding लागू की
  • नतीजतन query parsing 5.45 गुना और deparsing 9.64 गुना तेज़ हो गई

benchmark परिणाम

• benchmark को PgDog के fork repository में दोबारा चलाया जा सकता है
  • pg_query::parse (Protobuf): 613 QPS
  • pg_query::parse_raw (direct C–Rust): 3357 QPS
  • pg_query::deparse (Protobuf): 759 QPS
  • pg_query::deparse_raw (direct Rust–C): 7319 QPS

performance bottleneck analysis और caching प्रयास

• samply profiler से CPU time का analysis करने पर pg_query_parse_protobuf फ़ंक्शन bottleneck निकला
• caching के ज़रिए कुछ सुधार की कोशिश की गई
  • LRU algorithm-आधारित hashmap cache का उपयोग कर query text को key और AST को stored value के रूप में रखा गया
  • prepared statements के उपयोग पर reuse संभव था
• लेकिन कुछ ORM हज़ारों unique queries बनाते थे, और पुराने PostgreSQL drivers prepared statements को support नहीं करते थे, इसलिए cache efficiency कम रही

LLM की मदद से Protobuf हटाना

• PgDog टीम ने Claude LLM का उपयोग करके Protobuf हटाने वाले Rust bindings जनरेट किए
  • स्पष्ट और verify किए जा सकने वाले task scope में AI ने प्रभावी ढंग से काम किया
• Claude ने libpg_query के Protobuf spec के आधार पर C structs को Rust structs से map किया
  • 2 दिनों की iterative मेहनत के बाद 6,000 lines का recursive Rust code पूरा हुआ
• इसे parse, deparse, fingerprint, scan functions पर लागू किया गया, और pgbench के आधार पर 25% performance improvement की पुष्टि हुई

implementation की संरचनात्मक जानकारी

• Rust और C के बीच conversion में unsafe functions का उपयोग करके structs को सीधे map किया गया
  • C structs को Postgres API तक भेजकर AST बनाया गया, फिर उसे Rust में recursively convert किया गया
• हर AST node को convert_node फ़ंक्शन से process किया जाता है, जो SQL grammar के सैकड़ों tokens को map करता है
  • SELECT, INSERT जैसे हर node type के लिए अलग conversion functions मौजूद हैं
• conversion result में मौजूदा Protobuf struct (protobuf::ParseResult) का दोबारा उपयोग किया गया, जिससे tests में byte-level comparison validation संभव हुआ
• recursive algorithm में memory allocation कम होती है और CPU cache efficiency अधिक रहती है, इसलिए यह iterative implementation से तेज़ है
  • iterative implementation अनावश्यक memory allocation और hashmap lookups की वजह से उल्टा धीमी रही

निष्कर्ष

• Postgres parser का overhead घटाकर PgDog ने latency, memory और CPU usage तीनों कम किए
• इस optimization से PgDog और तेज़ तथा कम लागत पर चलने वाला PostgreSQL scaling proxy बन गया
• PgDog PostgreSQL के horizontal scaling (next iteration) को साथ मिलकर बनाने वाले engineers की भर्ती कर रहा है