मान लें कि id न केवल UNIQUE - जैसा कि आपके UNIQUE INDEX . द्वारा लागू किया गया है - लेकिन यह भी NOT NULL . (यह आपकी तालिका परिभाषा में अनुपलब्ध है।)
SELECT meta_split.key, meta_split.value, count(*)
FROM voc_cc348779bdc84f8aab483f662a798a6a v
CROSS JOIN LATERAL jsonb_each(v.meta) AS meta_split
GROUP BY meta_split.key, meta_split.value;
छोटा समकक्ष:
SELECT meta_split.key, meta_split.value, count(*)
FROM voc_cc348779bdc84f8aab483f662a798a6a v, jsonb_each(v.meta) AS meta_split
GROUP BY 1, 2;
LEFT [OUTER] JOIN शोर था क्योंकि निम्नलिखित परीक्षण WHERE meta_split.value IS NOT NULL एक INNER JOIN के लिए बाध्य करता है वैसे भी। CROSS JOIN का उपयोग करना इसके बजाय।
साथ ही, jsonb . के बाद से डुप्लीकेट कुंजियों को समान स्तर पर वैसे भी अनुमति नहीं देता (अर्थात् समान id केवल एक बार पॉप अप हो सकता है प्रति (key, value) ), DISTINCT सिर्फ महंगा शोर है। count(v.id) वही सस्ता करता है। और count(*) समतुल्य है, और सस्ता है, फिर भी - id . मानते हुए NOT NULL है जैसा कि ऊपर बताया गया है।
count(*) एक अलग कार्यान्वयन है
और count(<value>) . से थोड़ा तेज है . यह count(v.*) . से सूक्ष्म रूप से भिन्न है . यह सभी पंक्तियों को गिनता है, चाहे कुछ भी हो। जबकि दूसरा फॉर्म NULL . की गणना नहीं करता है मान।
यानी जब तक id NULL नहीं हो सकता - जैसा कि ऊपर बताया गया है। id वास्तव में PRIMARY KEY होना चाहिए , जो किसी भी तरह आंतरिक रूप से एक अद्वितीय बी-ट्री इंडेक्स के साथ कार्यान्वित किया जाता है, और सभी कॉलम - बस id यहाँ - हैं NOT NULL परोक्ष रूप से। या कम से कम NOT NULL . एक UNIQUE INDEX प्रतिस्थापन के रूप में पूरी तरह से योग्य नहीं है, यह अभी भी NULL . की अनुमति देता है मान जिन्हें समान नहीं माना जाता है और जिन्हें कई बार अनुमति दी जाती है। देखें:
इसके अलावा, यहां अनुक्रमणिका का कोई उपयोग नहीं है, क्योंकि सभी पंक्तियों को वैसे भी पढ़ा जाना है। तो यह कभी भी बहुत सस्ता नहीं होने वाला है। लेकिन 62k पंक्तियां किसी भी तरह से एक अपंग पंक्ति गणना नहीं है - जब तक कि आपके पास jsonb में बड़ी संख्या में कुंजियाँ न हों कॉलम।
इसे तेज करने के लिए शेष विकल्प:
-
अपने डिजाइन को सामान्य करें। JSON दस्तावेज़ों को अननेस्ट करना मुफ़्त नहीं है।
-
एक भौतिक दृष्टिकोण बनाए रखें। व्यवहार्यता और लागत दृढ़ता से आपके लेखन पैटर्न पर निर्भर करती है।
यहीं पर अनुक्रमणिकाएँ फिर से भूमिका निभा सकती हैं ...
