अपरिवर्तनीय, स्थिर और अस्थिर कीवर्ड फ़ंक्शन के व्यवहार को कैसे प्रभावित करते हैं?

कुंजी शब्द IMMUTABLE है कभी नहीं pgAdmin या Postgres द्वारा स्वचालित रूप से जोड़ा गया। जिसने भी फ़ंक्शन बनाया या बदला, उसने ऐसा किया।

सही अस्थिरता दिए गए फ़ंक्शन के लिए VOLATILE है (डिफ़ॉल्ट भी), नहीं STABLE - या clock_timestamp() . का उपयोग करने का कोई मतलब नहीं होगा जो VOLATILE . है now() . के विपरीत या CURRENT_TIMESTAMP जो STABLE . हैं :वे एक ही लेन-देन के भीतर एक ही टाइमस्टैम्प लौटाते हैं। मैनुअल:

clock_timestamp() वास्तविक वर्तमान समय लौटाता है, और इसलिए इसका मान एकल SQL कमांड में भी बदल जाता है।

मैनुअल चेतावनी देता है कि कार्य अस्थिरता STABLE ...

AFTER . के लिए अनुपयुक्त है ट्रिगर जो वर्तमान कमांड द्वारा संशोधित पंक्तियों को क्वेरी करना चाहते हैं।

.. क्योंकि ट्रिगर फ़ंक्शन का बार-बार मूल्यांकन भिन्न लौटा सकता है एक ही पंक्ति के लिए परिणाम। तो, नहीं STABLE ।

आप पूछते हैं:

क्या आपके पास इस बात का अंदाजा है कि IMMUTABLE के रूप में सेट होने पर पांचवें मान पर चिपके रहने से पहले फ़ंक्शन पांच बार सही ढंग से क्यों लौटा। ?

पोस्टग्रेज विकी:

9.2 के साथ, नियोजक भेजे गए मापदंडों के संबंध में विशिष्ट योजनाओं का उपयोग करेगा (क्वेरी को निष्पादन के लिए नियोजित किया जाएगा), सिवाय इसके कि यदि क्वेरी कई बार निष्पादित है और योजनाकार यह निर्णय लेता है कि सामान्य योजना विशिष्ट योजनाओं की तुलना में बहुत अधिक महंगी नहीं है।

बोल्ड जोर मेरा। IMMUTABLE . के लिए कोई अर्थ नहीं लगता इनपुट मापदंडों के बिना कार्य। लेकिन झूठे लेबल को VOLATILE . द्वारा ओवरराइड किया जाता है शरीर में कार्य (voids फ़ंक्शन इनलाइनिंग ):एक अलग क्वेरी योजना अभी भी समझ में आ सकती है। संबंधित:

• PostgreSQL संग्रहीत कार्यविधि प्रदर्शन

एक तरफ

trunc() floor() . से थोड़ा तेज़ है और यहां भी ऐसा ही करता है, क्योंकि सकारात्मक संख्याओं की गारंटी है:

SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int