जब सभी मान 36 वर्ण के होते हैं, तो क्या अनुक्रमणिका लुकअप चार बनाम चरच के साथ अधिक तेज़ी से दिखाई देगा

Question

मेरे पास एक लीगेसी स्कीमा (डिस्क्लेमर!) है जो सभी मेजों के लिए प्राथमिक कुंजी के लिए हैश-आधारित जेनरेट की गई आईडी का उपयोग करता है (इसमें कई हैं)। ऐसी आईडी का एक उदाहरण है:

922475bb-ad93-43ee-9487-d2671b886479

इस दृष्टिकोण को बदलने की कोई संभावित उम्मीद नहीं है, हालांकि सूचकांक पहुंच के साथ प्रदर्शन खराब है। कारणों की असंख्यता को अलग करते हुए, यह हो सकता है कि एक चीज पर ध्यान दिया जाए जो इष्टतम से कम प्रतीत होती है - सभी आईडी वैल्यू के बावजूद सभी कई तालिकाओं में लंबाई में कुल 36 अक्षर होने के बावजूद, कॉलम प्रकार है varchar(36), नहीं char(36) ।

कॉलम प्रकार को निश्चित लंबाई में बदलकर char(36)कोई महत्वपूर्ण सूचकांक प्रदर्शन लाभ प्रदान करेगा, जो प्रति सूचकांक पृष्ठ आदि प्रविष्टियों की संख्या में बहुत कम वृद्धि से परे है?

जब चर लंबाई प्रकारों की तुलना में स्थिर लंबाई प्रकारों के साथ काम करते हुए Ie पोस्टग्रेज बहुत तेजी से प्रदर्शन करता है?

कृपया माइनसक्यूल स्टोरेज सेविंग का उल्लेख न करें - कॉलम में बदलाव करने के लिए आवश्यक सर्जरी की तुलना में यह महत्वपूर्ण नहीं है।

Answer 1

नहीं, कोई लाभ नहीं । मैनुअल स्पष्ट रूप से बताता है :

युक्ति: इन तीन प्रकारों में कोई प्रदर्शन अंतर नहीं है , खाली-गद्देदार प्रकार का उपयोग करते समय भंडारण स्थान में वृद्धि के अलावा, और कुछ अतिरिक्त सीपीयू चक्रों को लंबाई-विवश स्तंभ में संग्रहीत करने के लिए लंबाई की जांच करने के लिए। जबकि character(n)कुछ अन्य डेटाबेस सिस्टम में प्रदर्शन लाभ हैं, PostgreSQL में ऐसा कोई लाभ नहीं है; वास्तव character(n)में इसकी अतिरिक्त भंडारण लागत के कारण आमतौर पर तीनों में से सबसे धीमा है। ज्यादातर स्थितियों में text या character varyingइसके बजाय इस्तेमाल किया जाना चाहिए ।

बोल्ड जोर मेरा।

char(n)काफी हद तक पुराना, बेकार प्रकार है। साथ रहना varchar(n)। यदि आपको लंबाई लागू करने की आवश्यकता नहीं है, varcharया textतेजी से थोड़ा सा होगा। आप एक अंतर को मापने में सक्षम नहीं होंगे।

इसके अलावा, अगर सभी तार लंबाई में ठीक 36 वर्ण हैं, तो किसी भी तरह से कोई बचत नहीं है, यहां तक ​​कि एक ऋण भी नहीं है। दोनों का डिस्क और रैम में समान आकार है। आप pg_column_size()(एक अभिव्यक्ति पर और एक तालिका स्तंभ पर) के साथ परीक्षण कर सकते हैं ।

सम्बंधित:

• तार के भंडारण के लिए डेटा प्रकार "पाठ" का उपयोग करने के किसी भी डाउनसाइड्स?

आपने अन्य विकल्प नहीं मांगे , लेकिन मैं दो का उल्लेख करूंगा:

1. COLLATION- जब तक आप "सी" कॉलेशन के साथ अपना डीबी नहीं चला रहे हैं । टकराव अक्सर अनदेखी की जाती है और संभवतः महंगी होती है। चूँकि आपके तार किसी प्राकृतिक भाषा में सार्थक नहीं लगते हैं, इसलिए निम्नलिखित COLLATIONनियमों का कोई मतलब नहीं है। सम्बंधित:

   • मैं कुशलतापूर्वक "सबसे हाल की संगत पंक्ति" कैसे प्राप्त करूं?
   • अनुक्रमणिका का उपयोग नहीं कर समारोह के भीतर बाहर निकलें?

   व्यापक बेंचमार्क तुलना (अन्य के बीच) COLLATE "C"प्रदर्शन का प्रभाव :

   • ज्वाइन टेबल में एक कॉलम द्वारा स्लो क्वेरी ऑर्डर

2. UUID , जाहिर है। आपका स्ट्रिंग संदिग्ध रूप से UUID (32 हेक्स अंक प्लस 4 सीमांकक) जैसा दिखता है। यह वास्तविकuuidडेटा प्रकार केरूप में संग्रहीत करने के लिए बहुत अधिक कुशल होगा, जो कई मायनों में तेज है और केवल 16 बाइट्स परकब्जाकरता है - जैसा कियातो रैम के लिए 37 बाइट्स केविपरीत हैchar(36)याvarchar(36)(सीमांकक के बिना संग्रहीत, बस 32 डिफाइनिंग चार्ज), या 33 डिस्क पर बाइट्स। लेकिन संरेखण पैडिंग के परिणामस्वरूपकई मामलोंमें 40 बाइट्स हो सकते हैं।)डेटा प्रकार केCOLLATIONलिए भी अप्रासंगिक होगाuuid।

   SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid

   यह सहायक हो सकता है (अंतिम अध्याय):

   • दशमलव संख्या में पाठ प्रतिनिधित्व में हेक्स परिवर्तित करें

   यह भी देखें:

   • Varchar (n) के लिए ओवरहेड क्या है?
   • MD5 फ़ील्ड के लिए इष्टतम डेटा प्रकार क्या है?

Comments

क्या इसका मतलब यह है कि एक लंबी बाधा चार / चरचर (एन) बाधा की जांच में सीपीयू चक्र खर्च करेगा, जबकि चर लंबाई पाठ क्षेत्र चार की तुलना में कम सुलभ तरीके से पाठ को अलग से संग्रहीत करेगा, जो इस परिदृश्य में जीतता है और यह जीत है पाठ के एक टुकड़े के साथ 10 मिलियन पंक्तियों को कहने के लिए भी विचार करने योग्य है

— PirateApp

@PirateApp: किसी भी सम्मान में char(n)लगभग कभी नहीं जीतता है। इसका उपयोग न करें। डेटा प्रकार textऔर varchar(लंबाई संशोधक के बिना) बाइनरी संगत हैं और समान प्रदर्शन विशेषताओं को साझा करते हैं। वहाँ के लिए ऐतिहासिक कारणों से कर रहे हैं दोनों Postgres में रह सकते हैं। आंतरिक रूप से, textस्ट्रिंग प्रकारों के बीच "पसंदीदा" प्रकार है (जो फ़ंक्शन प्रकार रिज़ॉल्यूशन को प्रभावित कर सकता है)। सीपीयू varchar(n)मुश्किल से बात को लागू करने के लिए चक्र । जरूरत पड़ने पर लंबाई प्रतिबंध का प्रयोग करें । मामले में हाथ uuidमें असली विजेता है।

— एरविन ब्रान्डेसटेटर