उत्तर सीधा है।
SQL सर्वर CTE को अमल में नहीं लाता है। यह उन्हें इनलाइन करता है, जैसा कि आप निष्पादन योजनाओं से देख सकते हैं।
अन्य डीबीएमएस इसे अलग तरीके से लागू कर सकते हैं, एक प्रसिद्ध उदाहरण पोस्टग्रेस है, जो सीटीई को अमल में लाता है (यह अनिवार्य रूप से हुड के पीछे सीटीई के लिए अस्थायी टेबल बनाता है)।
क्या स्पष्ट अस्थायी तालिकाओं में मध्यस्थ परिणामों का स्पष्ट भौतिककरण तेजी से होता है, यह क्वेरी पर निर्भर करता है।
जटिल प्रश्नों में मध्यस्थ डेटा को अस्थायी तालिकाओं में लिखने और पढ़ने के ओवरहेड को अधिक कुशल सरल निष्पादन योजनाओं द्वारा ऑफसेट किया जा सकता है जो ऑप्टिमाइज़र उत्पन्न करने में सक्षम है।
दूसरी ओर, Postgres में CTE एक "ऑप्टिमाइज़ेशन फ़ेंस" है और इंजन विधेय को CTE सीमा के पार नहीं धकेल सकता है।
कभी एक रास्ता बेहतर होता है तो कभी दूसरा। एक बार जब क्वेरी जटिलता निश्चित सीमा से आगे बढ़ जाती है तो एक ऑप्टिमाइज़र डेटा को संसाधित करने के सभी संभावित तरीकों का विश्लेषण नहीं कर सकता है और उसे किसी चीज़ पर समझौता करना पड़ता है। उदाहरण के लिए, तालिकाओं में शामिल होने का क्रम। चुनने के लिए तालिकाओं की संख्या के साथ क्रमपरिवर्तन की संख्या तेजी से बढ़ती है। ऑप्टिमाइज़र के पास योजना बनाने के लिए सीमित समय होता है, इसलिए जब सभी सीटीई इनलाइन होते हैं तो यह खराब विकल्प बना सकता है। जब आप जटिल क्वेरी को मैन्युअल रूप से छोटे सरल प्रश्नों में तोड़ते हैं, तो आपको यह समझने की आवश्यकता होती है कि आप क्या कर रहे हैं, लेकिन ऑप्टिमाइज़र के पास प्रत्येक साधारण क्वेरी के लिए एक अच्छी योजना बनाने का बेहतर मौका होता है।
