मैं क्लाइंट-साइड पर्ल इंटरफ़ेस के बारे में बात नहीं कर सकता, लेकिन मैं PostgreSQL सर्वर साइड पर कुछ प्रकाश डाल सकता हूं।
PostgreSQL ने बयान और तैयार नहीं किए गए बयान तैयार किए हैं। बिना तैयारी के बयानों को तुरंत पार्स, नियोजित और निष्पादित किया जाता है। वे नहीं भी करते हैं समर्थन पैरामीटर प्रतिस्थापन। एक सादे psql . पर खोल आप उनकी क्वेरी योजना इस तरह दिखा सकते हैं:
tmpdb> explain select * from sometable where flag = true;
दूसरी ओर तैयार किए गए बयान हैं:वे आम तौर पर (नीचे "अपवाद" देखें) एक चरण में पार्स और योजनाबद्ध होते हैं और दूसरे चरण में निष्पादित होते हैं। उन्हें विभिन्न मापदंडों के साथ कई बार फिर से निष्पादित किया जा सकता है, क्योंकि वे करते हैं समर्थन पैरामीटर प्रतिस्थापन। psql . में समतुल्य क्या यह है:
tmpdb> prepare foo as select * from sometable where flag = $1;
tmpdb> explain execute foo(true);
आप देख सकते हैं, कि योजना तैयार नहीं किए गए विवरण में योजना से अलग है, क्योंकि योजना पहले से ही prepare में हो चुकी थी चरण PREPARE
के लिए दस्तावेज़ में वर्णित है। :
इसका मतलब यह भी है कि योजना नहीं है प्रतिस्थापित मापदंडों के लिए अनुकूलित:पहले उदाहरणों में flag . के लिए एक अनुक्रमणिका का उपयोग किया जा सकता है क्योंकि PostgreSQL जानता है कि दस लाख प्रविष्टियों के भीतर केवल दस का मान true है . यह तर्क असंभव है जब PostgreSQL एक तैयार कथन का उपयोग करता है। उस स्थिति में एक योजना बनाई जाती है जो यथासंभव सभी संभावित पैरामीटर मानों के लिए काम करेगी। यह हो सकता है उल्लिखित इंडेक्स को बाहर करें क्योंकि रैंडम एक्सेस (इंडेक्स के कारण) के माध्यम से पूरी तालिका के बेहतर हिस्से को प्राप्त करना एक सादे अनुक्रमिक स्कैन की तुलना में धीमा है। तैयारी
doc इसकी पुष्टि करता है:
BTW - PREPARE योजना कैशिंग के संबंध में doc को भी कुछ कहना है:
इसके अलावा कोई स्वचालित योजना कैशिंग नहीं है और एकाधिक कनेक्शन पर कोई कैशिंग/पुन:उपयोग नहीं है।
अपवाद :मैंने "आमतौर पर" का उल्लेख किया है। दिखाया गया psql उदाहरण वे सामान नहीं हैं जो क्लाइंट एडॉप्टर जैसे पर्ल डीबीआई वास्तव में उपयोग करता है। यह एक निश्चित प्रोटोकॉल
का उपयोग करता है . यहाँ "सरल क्वेरी" शब्द psql में "अप्रस्तुत क्वेरी" से मेल खाता है , शब्द "विस्तारित क्वेरी " एक अपवाद के साथ "तैयार क्वेरी" से मेल खाता है:(एक) "अनाम कथन" और (संभवतः एकाधिक) "नामित कथन" के बीच एक अंतर है। नामित बयानों के संबंध में doc
कहते हैं:
और यह भी:
तो इस मामले में नियोजन बिना पैरामीटर के किया जाता है जैसा कि ऊपर वर्णित PREPARE . के लिए किया गया है - कोई नई बात नहीं।
उल्लिखित अपवाद "अनाम कथन" है। डॉक्टर कहते हैं:
और यहां लाभ है:हालांकि अनाम कथन "तैयार" है (यानी पैरामीटर प्रतिस्थापन हो सकता है), यह वास्तविक पैरामीटर के लिए क्वेरी योजना को भी अनुकूलित कर सकता है।
BTW:PostgreSQL सर्वर के पिछले रिलीज़ में अनाम कथन की सटीक हैंडलिंग कई बार बदली है। यदि आप वास्तव में चाहते हैं तो आप विवरण के लिए पुराने दस्तावेज़ देख सकते हैं।
तर्क - पर्ल / कोई भी ग्राहक :
कैसे एक ग्राहक जैसे पर्ल प्रोटोकॉल का उपयोग करता है एक पूरी तरह से अलग सवाल है। जावा के लिए जेडीबीसी ड्राइवर जैसे कुछ क्लाइंट मूल रूप से कहते हैं:भले ही प्रोग्रामर एक तैयार कथन का उपयोग करता है, पहले पांच (या तो) निष्पादन आंतरिक रूप से "सरल क्वेरी" (यानी प्रभावी रूप से तैयार नहीं) में मैप किए जाते हैं, उसके बाद ड्राइवर स्विच करता है " नामित बयान"।
तो क्लाइंट के पास ये विकल्प होते हैं:
- हर बार "सरल क्वेरी" प्रोटोकॉल का उपयोग करके बलपूर्वक (पुनः) योजना बनाना।
- योजना एक बार, "विस्तारित क्वेरी" प्रोटोकॉल और "नामित कथन" का उपयोग करके कई बार निष्पादित करें (योजना खराब हो सकती है क्योंकि योजना मापदंडों के बिना की जाती है)।
- पार्स एक बार, "विस्तारित क्वेरी" प्रोटोकॉल और "अनाम कथन" का उपयोग करके प्रत्येक निष्पादन (वर्तमान PostgreSQL संस्करण के साथ) की योजना बनाएं और कुछ और चीजों का पालन करें ("पार्स" संदेश के दौरान कुछ पैरा प्रदान करें)
- JDBC ड्राइवर की तरह पूरी तरह से अलग चालें चलाएं।
पर्ल वर्तमान में क्या करता है:मुझे नहीं पता। लेकिन उल्लेखित "रेड हेरिंग" बहुत कम संभावना नहीं है।
