Postgresql join_collapse_limit और क्वेरी प्लानिंग का समय

समस्या यह है कि N . के लिए सर्वश्रेष्ठ जॉइन ऑर्डर खोजने की योजना बना रहे हैं टेबल एक O(N!) takes लेता है (तथ्यात्मक) दृष्टिकोण। और इसलिए, वृद्धि की संख्या बहुत अधिक है, आप इसे निम्न क्वेरी के साथ आसानी से देख सकते हैं:

$ SELECT i, (i)! AS num_comparisons FROM generate_series(8, 20) i;
 i  |   num_comparisons   
----+---------------------
  8 |               40320
  9 |              362880
 10 |             3628800
 11 |            39916800
 12 |           479001600
 13 |          6227020800
 14 |         87178291200
 15 |       1307674368000
 16 |      20922789888000
 17 |     355687428096000
 18 |    6402373705728000
 19 |  121645100408832000
 20 | 2432902008176640000
(13 rows)

जैसा कि आप देख सकते हैं, 8 के डिफ़ॉल्ट पर हम लगभग 40K तुलना करते हैं, आपके द्वारा प्रस्तावित 10 इसे 3M तक ले जाता है, जो अभी भी आधुनिक कंप्यूटरों के लिए बहुत अधिक नहीं है, लेकिन अगले मान बहुत बड़े होने लगते हैं, यह बस बढ़ जाता है बहुत तेज़, 20 बस पागल है (21! 64 बिट पूर्णांक भी फिट नहीं बैठता)।

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

मेरे अनुभव में, मैं अच्छे सर्वर में किसी भी इंस्टॉलेशन पर 10 को डिफ़ॉल्ट मान के रूप में मानता हूं, उनमें से कुछ मैं 12 का भी उपयोग करता हूं। मैं आपको इसे 10 पर सेट करने की सलाह देता हूं, और कभी-कभी, इसे उच्च सेट करने का प्रयास करें ( मैं 12 से आगे नहीं जाऊंगा) और यह कैसे व्यवहार करता है यह देखने के लिए निगरानी (बारीकी से) करता हूं।