जिस कारण से आप एक अंतर देख रहे हैं वह निष्पादन योजना के कारण है जिसे योजनाकार एक साथ रख रहा है, यह स्पष्ट रूप से क्वेरी के आधार पर अलग है (यकीनन, यह 2 प्रश्नों को समान होने के लिए अनुकूलित करना चाहिए और यह एक बग हो सकता है ) इसका मतलब यह है कि योजनाकार सोचता है कि प्रत्येक कथन में परिणाम प्राप्त करने के लिए उसे एक विशेष तरीके से काम करना होगा।
जब आप इसे जॉइन के भीतर करते हैं, तो योजनाकार को शायद तालिका से चयन करना होगा, "ट्रू" भाग द्वारा फ़िल्टर करना होगा, फिर परिणाम सेट में शामिल होना होगा। मुझे लगता है कि यह एक बड़ी तालिका है, और इसलिए देखने के लिए बहुत सारे डेटा हैं, और यह इंडेक्स का कुशलतापूर्वक उपयोग नहीं कर सकता है।
मुझे संदेह है कि यदि आप इसे WHERE क्लॉज में करते हैं, तो योजनाकार एक ऐसा मार्ग चुन रहा है जो अधिक कुशल है (यानी या तो इंडेक्स आधारित, या पूर्व फ़िल्टर किए गए डेटासेट)।
आप शायद दो स्तंभों पर एक अनुक्रमणिका जोड़कर शामिल होने का कार्य तेज़ (यदि तेज़ नहीं) कर सकते हैं (सुनिश्चित नहीं हैं कि शामिल स्तंभ और एकाधिक स्तंभ अनुक्रमणिका अभी तक Postgres पर समर्थित हैं)।
संक्षेप में, योजनाकार वह समस्या है जो परिणाम सेट तक पहुंचने के लिए 2 अलग-अलग मार्गों को चुन रहा है, और उनमें से एक दूसरे की तरह कुशल नहीं है। तालिका की पूरी जानकारी और व्याख्या विश्लेषण जानकारी के बिना यह जानना हमारे लिए असंभव है कि इसके क्या कारण हैं।
यदि आप इस बारे में विशिष्ट जानकारी चाहते हैं कि आपकी विशिष्ट क्वेरी ऐसा क्यों कर रही है, तो आपको अधिक जानकारी प्रदान करने की आवश्यकता होगी। हालांकि कारण यह है कि योजनाकार विभिन्न मार्गों को चुन रहा है।
अतिरिक्त पठन सामग्री:
http://www.postgresql.org/docs/current/static/explicit-joins.html
बस स्किम्ड, ऐसा लगता है कि पोस्टग्रेज प्लानर इसे ऑप्टिमाइज़ करने के लिए फिर से ऑर्डर नहीं करता है। अपने कथन में शामिल होने के क्रम को बदलने का प्रयास करें यह देखने के लिए कि क्या आपको वही प्रदर्शन मिलता है... बस एक विचार।
