चूंकि आप दो बड़ी तालिकाओं में शामिल हो रहे हैं और ऐसी कोई स्थिति नहीं है जो पंक्तियों को फ़िल्टर कर सकती है, केवल कुशल जुड़ने की रणनीति हैश जॉइन होगी, और कोई भी इंडेक्स इसमें मदद नहीं कर सकता है।
सबसे पहले एक टेबल का अनुक्रमिक स्कैन होगा, जिसमें से हैश संरचना बनाई गई है, फिर दूसरी टेबल पर अनुक्रमिक स्कैन होगा, और हैश की प्रत्येक पंक्ति के लिए जांच की जाएगी। कोई इंडेक्स इसमें कैसे मदद कर सकता है?
आप इस तरह के ऑपरेशन में लंबा समय लगने की उम्मीद कर सकते हैं, लेकिन कुछ तरीके हैं जिनसे आप ऑपरेशन को तेज कर सकते हैं:
-
tx_input1. पर सभी इंडेक्स और बाधाओं को हटा दें शुरू करने से पहले। आपकी क्वेरी उन उदाहरणों में से एक है जहां एक इंडेक्स बिल्कुल भी मदद नहीं करता है, लेकिन वास्तव में दर्द करता है प्रदर्शन, क्योंकि अनुक्रमणिका को तालिका के साथ अद्यतन किया जाना है।UPDATE. के साथ काम पूरा करने के बाद अनुक्रमणिका और बाधाओं को फिर से बनाएँ . टेबल पर मौजूद इंडेक्स की संख्या के आधार पर, आप अच्छे से बड़े प्रदर्शन की उम्मीद कर सकते हैं। -
work_memबढ़ाएँSET. के साथ इस एक ऑपरेशन के लिए पैरामीटर जितना हो सके उतना ऊंचा आदेश दें। हैश ऑपरेशन जितनी अधिक मेमोरी का उपयोग कर सकता है, उतनी ही तेजी से होगा। इतनी बड़ी तालिका के साथ आपके पास शायद अभी भी अस्थायी फ़ाइलें होंगी, लेकिन आप अभी भी एक अच्छे प्रदर्शन की उम्मीद कर सकते हैं। -
बढ़ाएँ
checkpoint_segments(याmax_wal_sizeसंस्करण 9.6 से) को उच्च मान तक ले जाएं ताकिUPDATEके दौरान कम चौकियां हों ऑपरेशन। -
सुनिश्चित करें कि दोनों तालिकाओं पर तालिका आँकड़े सटीक हैं, ताकि PostgreSQL हैश बकेट की संख्या के निर्माण के लिए एक अच्छा अनुमान लगा सके।
UPDATE के बाद , यदि यह बड़ी संख्या में पंक्तियों को प्रभावित करता है, तो आप VACUUM (FULL) चलाने पर विचार कर सकते हैं tx_input1 . पर परिणामी टेबल ब्लोट से छुटकारा पाने के लिए। यह टेबल को अधिक समय के लिए लॉक कर देगा, इसलिए इसे रखरखाव विंडो के दौरान करें। यह तालिका के आकार को कम करेगा और परिणामस्वरूप क्रमिक स्कैन को गति देगा।
