धीमी गति से चलने वाली पोस्टग्रेज क्वेरी

धीमेपन का कारण खराब पंक्ति गणना अनुमान हैं जो PostgreSQL को नेस्टेड लूप में शामिल होने का चयन करते हैं। आपका लगभग सारा समय hfj_res_link . पर अनुक्रमणिका स्कैन में व्यतीत होता है , जिसे 1113 बार दोहराया जाता है।

मेरा पहला प्रयास होगा ANALYZE hfj_spidx_date और देखें कि क्या इससे मदद मिलती है। यदि हाँ, तो सुनिश्चित करें कि स्वतः विश्लेषण उस तालिका का अधिक बार उपयोग करता है।

अगला प्रयास होगा

SET default_statistics_target = 1000;

और फिर ANALYZE ऊपरोक्त अनुसार। अगर इससे मदद मिलती है, तो ALTER TABLE . का उपयोग करें STATISTICS को बढ़ाने के लिए hash_identity . पर और sp_value_high कॉलम।

यदि वह भी मदद नहीं करता है, और आपके पास PostgreSQL का नवीनतम संस्करण है, तो आप विस्तारित आँकड़े आज़मा सकते हैं :

CREATE STATISTICS myparamsda2_stats (dependencies)
   ON hash_identity, sp_value_high FROM hfj_spidx_date;

फिर ANALYZE तालिका फिर से देखें और देखें कि क्या इससे मदद मिलती है।

यदि वह सब मदद नहीं करता है, और आप अनुमानों को सही नहीं कर सकते हैं, तो आपको एक अलग कोण का प्रयास करना होगा:

CREATE INDEX ON hfj_res_link (target_resource_id, src_resource_id);

इससे इंडेक्स स्कैन में काफी तेजी आनी चाहिए और आपको अच्छी प्रतिक्रिया समय देना चाहिए।

अंत में, यदि उपरोक्त में से किसी का भी कोई प्रभाव नहीं पड़ता है, तो आप इस क्वेरी के लिए नेस्टेड लूप जॉइन को अस्वीकार करने के क्रूस उपाय का उपयोग कर सकते हैं:

BEGIN;
SET LOCAL enable_nestloop = off;
SELECT /* your query goes here */;
COMMIT;