क्या VARCHAR कॉलम को अनुक्रमित करना एक अच्छा विचार / दृष्टिकोण है?

32

हम PostgreSQL v8.2.3 का उपयोग कर रहे हैं।

इसमें शामिल टेबल हैं: EMPLOYEE और EMAILLIST ।

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2 तालिकाओं को इस तरह से जोड़ा जाता है कि यदि या तो EMPLOYEE.EMAIL1 या EMPLOYEE.EMAIL2 में मेल खाने वाली प्रविष्टि नहीं है, तो उन पंक्तियों को वापस कर दिया जाएगा।

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

स्तंभ EMAILजो है varchar (256) की EMAILLISTतालिका अनुक्रमित है। अब, प्रतिक्रिया समय 14 सेकंड है।

सारणी गणना के आँकड़े: वर्तमान में, EMPLOYEE को 165,018 रिकॉर्ड और EMAILLIST को 1,810,228 रिकॉर्ड मिले हैं, और दोनों तालिका भविष्य में बढ़ने की उम्मीद है।

क्या VARCHAR कॉलम को अनुक्रमित करना एक अच्छा विचार / दृष्टिकोण है? इस सवाल ने मेरे दिमाग पर तुरंत हमला कर दिया क्योंकि इस कारण से कि हमने अपने आवेदन से पहले VARCHAR कॉलम को अनुक्रमित नहीं किया है। इस पर विशेषज्ञों की सलाह / सुझाव काफी सराहे जाते हैं।
इस वर्तमान क्वेरी और इंडेक्स के साथ, 14 सेकंड का प्रतिक्रिया समय उचित है या आगे ट्यूनिंग के लिए कोई गुंजाइश है? इस प्रकार की तालिका आकार और प्रतिक्रिया समय के आधार पर अन्य उपयोगकर्ता का वास्तविक समय का अनुभव / राय क्या है?

नोट: मेरी वास्तविक आवश्यकता / उपयोग मामला यहाँ विस्तार से बताया गया है ।

— Gnanam
स्रोत

25

यदि आप इसके आधार पर क्वेरीज़ करने जा रहे हैं, तो varchar कॉलम को अनुक्रमित करने में कुछ भी गलत नहीं है। हालाँकि कृपया ध्यान रखें कि कुछ अनुक्रमित और एक क्षेत्र में वे कितना सूचकांक कर सकते हैं। उदाहरण आप उस कॉलम को अनुक्रमित नहीं कर सकते हैं जिसमें असीमित मात्रा में पाठ हो सकते हैं। हालाँकि आपको बिना किसी समस्या के varchar (256) पर एक इंडेक्स करने में सक्षम होना चाहिए। इसे आज़माएं, और यह देखने में सुधार करने के लिए कि क्या यह मदद करता है, अपने प्रश्नों के प्रदर्शन में सुधार का विश्लेषण करें।

— xenoterracide
स्रोत

आपकी बहुमूल्य टिप्पणी के लिए धन्यवाद। 14 सेकंड से प्रतिक्रिया समय कम करने के लिए क्या इस संबंध में मेरी क्वेरी को आगे बढ़ाने की कोई गुंजाइश है?

— ज्ञानम

2

EXPLAIN के परिणामों के बिना, यह बताना असंभव है कि क्या अनुकूलित करना है। संस्करण 8.2.3 भी पुराना है, आपको एक नए संस्करण में अपग्रेड करना चाहिए, आप रखरखाव में 4 साल पीछे हैं। संस्करण 8.3, 8.4 और 9.0 भी कई स्थितियों में तेज हैं। बेहतर आंकड़े भी प्रदर्शन हासिल करने में मदद करते हैं।

— फ्रैंक हाइकेन

5

इस तरह के रूप में एक varchar स्तंभ अनुक्रमणिका कोई समस्या नहीं है

जहां यह एक मुद्दा बन सकता है जब आपके पास एक अरब पंक्ति की तालिका में FK के रूप में varchar स्तंभ हो। फिर आपके पास PK और FK के लिए एक सरोगेट कुंजी होगी, लेकिन आपको अभी भी प्राकृतिक बॉरोकेट कुंजी पर एक अद्वितीय बाधा / सूचकांक की आवश्यकता होगी।

आपकी टेबल काफी छोटी हैं और प्रदर्शन OR क्लॉज से संबंधित हो सकता है। दुर्भाग्य से, एक ही मुद्दा लागू होता है कोई बात नहीं कि आप क्वेरी कैसे बनाते हैं (और मैं बहुत खेद व्यक्त करने के लिए PostgresSQL से परिचित नहीं हूं)

— GBN
स्रोत

0

अपनी क्वेरी के "या e2.email IS NULL" भाग से छुटकारा पाने की कोशिश करें और देखें कि यह कितनी तेजी से चलता है। यदि यह तेजी से चलता है, तो आप इसे "यूनियन ऑल" के साथ जल्दी चला सकते हैं

— जो प्यार
स्रोत