• Python 3.13 में नया JIT compiler बनाने की methodology (copy-patch) जोड़े जाने के बाद, इसे PostgreSQL पर लागू करने का निर्णय लिया गया।
  • pg-copyjit नाम का एक नया तरीका पेश किया गया है, जो PostgreSQL server की गति बढ़ाने का तरीका है।
  • सारा code experimental है, और इसे वास्तविक production environment में इस्तेमाल करने से पहले विशेषज्ञ समीक्षा आवश्यक है।

शुरुआत में JIT नहीं था, फिर LLVM JIT compiler आया

  • PostgreSQL में LLVM-आधारित JIT compilation जोड़ी गई थी, लेकिन LLVM में ऐसे पहलू हैं जो JIT compilation के लिए उपयुक्त नहीं हैं।
  • LLVM optimization महंगी है, और अगर उसे इस्तेमाल न किया जाए तो compilation स्वयं ही अर्थहीन हो सकती है।
  • PostgreSQL का query cost estimation वास्तविक execution time से सीधे जुड़ा नहीं है, इसलिए कई उपयोगकर्ता JIT compiler को disable कर देते हैं।

2021 में copy-and-patch का वर्णन किया गया

  • जितनी जल्दी संभव हो, तेज़ और पर्याप्त code generate करने की आवश्यकता है।
  • copy-patch तरीका C में लिखे गए stencil (template functions) का उपयोग करके code को तेज़ी से generate करता है।
  • stencil को नई memory area में copy करके, holes को भर दिया जाता है और सीधे 'compiled' function पर jump किया जा सकता है।

PostgreSQL में copy-and-patch लाना

  • PostgreSQL में नया JIT engine बनाना बहुत कठिन नहीं है, और यह प्रस्तावित है कि LLVM को plugin बनाया जाए ताकि दूसरे JIT compiler भी जोड़े जा सकें।
  • एकल _PG_jit_provider_init function देना और compile_expr, release_context, reset_after_error इन तीन callbacks को initialize करना पर्याप्त है।
  • copy-patch algorithm सरल है: हर opcode के लिए stencil खोजकर जोड़ा जाता है, और आवश्यक values को holes में भरा जाता है।

वर्तमान स्थिति

  • यह PostgreSQL 16 पर काम करता है, और फिलहाल केवल AMD64 को support करता है।
  • code generation कुछ सौ microseconds में पूरा हो जाता है, इसलिए छोटे queries में भी इसका उपयोग संभव है।
  • अभी optimization चरण नहीं है, लेकिन performance पहले ही interpreter की तुलना में बेहतर दिख रही है।
  • implemented opcode कम हैं, लेकिन जिन queries को अभी support नहीं किया जाता, उनके लिए PostgreSQL interpreter fallback के रूप में चलता है।

आगे क्या करना है...

  • यह proof-of-concept चरण में है, और इसे आसानी से build या package करने योग्य बनाना अभी लक्ष्य नहीं है।
  • अधिक opcode implement करने और optimization ढूंढने पर ध्यान दिया जा रहा है।
  • दूसरी architectures पर port करना भी गंभीरता से विचाराधीन है।

आभार

  • अपने वर्तमान कार्यस्थल Entr’ouvert का धन्यवाद, जिसने सहकर्मियों को इस project पर समय देने के लिए समर्थन दिया।
  • DBA मित्रों का भी धन्यवाद, और PoWA आज़माने की सिफारिश की गई है।

GN⁺ की राय

  • यह लेख PostgreSQL database server की performance बेहतर करने के लिए एक नया approach पेश करता है। यह database administrators और developers के लिए दिलचस्प हो सकता है।
  • experimental code को वास्तविक production environment में लागू करने से पहले गहन testing और validation आवश्यक है। इसका उद्देश्य data loss या downtime जैसे जोखिमों को रोकना है।
  • LLVM जैसे मौजूदा JIT compiler की तुलना में copy-patch तरीका तेज़ code generation संभव बनाता है, जिससे यह छोटे queries में भी उपयोगी हो सकता है।
  • अगर इस तकनीक को PostgreSQL community में व्यापक स्वीकृति मिलती है, तो विभिन्न architectures के लिए support विस्तार के साथ database performance optimization में एक नया अध्याय खुल सकता है।
  • आलोचनात्मक दृष्टि से देखें तो यह अभी शुरुआती चरण में है, और वास्तविक production environment में performance improvement कैसी दिखेगी, इसके लिए और अधिक research तथा development की आवश्यकता है।

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.