क्या पोस्टग्रेज़ का विश्लेषण करने के लिए कोई उपकरण या विधि है, और यह निर्धारित करें कि क्या लापता इंडेक्स बनाए जाना चाहिए, और कौन से अप्रयुक्त इंडेक्स को हटाया जाना चाहिए? SQLServer के लिए "प्रोफाइलर" टूल के साथ मुझे ऐसा करने का थोड़ा सा अनुभव है, लेकिन मुझे पोस्टग्रेस के साथ शामिल एक समान टूल से अवगत नहीं है।PostgreSQL सूचकांक उपयोग विश्लेषण
मुझे यह पसंद लापता अनुक्रमित लगता है:
SELECT schemaname, relname, seq_scan-idx_scan AS too_much_seq, case when seq_scan-idx_scan>0 THEN 'Missing Index?' ELSE 'OK' END, pg_relation_size(format('%I.%I', schemaname, relname)::regclass) AS rel_size, seq_scan, idx_scan
FROM pg_stat_user_tables
WHERE pg_relation_size(format('%I.%I', schemaname, relname)::regclass)>80000 ORDER BY too_much_seq DESC;
यह जांच करता है कि वहाँ अधिक अनुक्रम स्कैन तो सूचकांक स्कैन कर रहे हैं। यदि तालिका छोटी है, तो इसे अनदेखा कर दिया जाता है, क्योंकि पोस्टग्रेस उनके लिए अनुक्रम स्कैन पसंद करते हैं।
उपरोक्त क्वेरी में लापता इंडेक्स प्रकट होते हैं।
अगला चरण लापता संयुक्त सूचकांक का पता लगाने के लिए होगा। मुझे लगता है कि यह आसान नहीं है, लेकिन करने योग्य है। शायद धीमी क्वेरी का विश्लेषण ... मैंने सुना है pg_stat_statements मदद कर सकता है ...
उद्धृत पहचानकर्ताओं के साथ यह काम करने के लिए क्वेरी को बदलें: 'SELECT relname, seq_scan-idx_scan AS_much_seq, केस जब seq_scan-idx_scan> 0 फिर' अनुपलब्ध अनुक्रमणिका? ' अन्य सभी 'ठीक है' अंत, pg_relation_size (relid :: regclass) के रूप में rel_size, seq_scan, idx_scan pg_stat_all_tables से कहां schemaname = 'सार्वजनिक' और pg_relation_size (relid :: regclass)> 80000 आदेश द्वारा too_much_seq DESC; ' –
के उत्पादन इस प्रश्न को उत्तर को और अधिक उपयोगी बनाने के लिए समझाया जाना चाहिए – cen
@ सेन के बिंदु पर, जब 'too_much_seq' सकारात्मक और बड़ा है, तो आपको चिंतित होना चाहिए। – mountainclimber
यह मदद करनी चाहिए: Pratical Query Analysis
पीक्यूए का अंतिम अपडेट कई साल पुराना है। क्या यह एक सुविधा है जो pgFouine द्वारा समर्थित नहीं है? – guettli
निर्धारित लापता अनुक्रमित पर दृष्टिकोण .... नहीं। लेकिन भविष्य में रिलीज में इसे आसान बनाने की कुछ योजनाएं हैं, जैसे छद्म-इंडेक्स और मशीन पठनीय एक्स्पलाइन।
वर्तमान में, आपको EXPLAIN ANALYZE खराब प्रदर्शन करने वाले प्रश्नों की आवश्यकता होगी और फिर मैन्युअल रूप से सर्वोत्तम मार्ग निर्धारित करें। कुछ लॉग विश्लेषक pgFouine जैसे प्रश्नों को निर्धारित करने में मदद कर सकते हैं।
select * from pg_stat_all_indexes where schemaname <> 'pg_catalog';
यह मदद मिलेगी tuples पढ़ा, स्कैन किए गए, प्राप्त किए गए पहचान:
जहाँ तक एक अप्रयुक्त सूचकांक के रूप में, आप कुछ उन्हें पहचान करने में मदद करने के लिए निम्न की तरह उपयोग कर सकते हैं।
फ्रैंक हेइकेंस भी वर्तमान सूचकांक उपयोग पर पूछताछ के लिए अन्य स्थानों पर कुछ अच्छी जगहों को इंगित करता है। – rfusca
आंकड़ों की जांच करें। pg_stat_user_tables और pg_stat_user_indexes शुरुआत करने वाले हैं।
"The Statistics Collector" देखें।
स्क्रिप्ट्स के कई लिंक हैं जो आपको PostgreSQL wiki पर अप्रयुक्त अनुक्रमणिका ढूंढने में मदद करेंगे। मूल तकनीक pg_stat_user_indexes को देखने और idx_scan को देखने के लिए है, यह जानने के लिए कि क्वेरी का उत्तर देने के लिए कितनी बार इंडेक्स का उपयोग किया गया है, शून्य है, या कम से कम बहुत कम है। यदि एप्लिकेशन बदल गया है और पहले इस्तेमाल किया गया सूचकांक शायद अब नहीं है, तो आपको कभी-कभी सभी आंकड़े 0 पर वापस लाने के लिए pg_stat_reset() चलाएं और फिर नया डेटा एकत्र करें; आप सबकुछ के लिए मौजूदा मानों को सहेज सकते हैं और इसे समझने के बजाय डेल्टा की गणना कर सकते हैं।
अनुपलब्ध इंडेक्स का सुझाव देने के लिए अभी तक कोई भी अच्छा टूल उपलब्ध नहीं है। एक दृष्टिकोण यह है कि आप जिन प्रश्नों को चला रहे हैं उन्हें लॉग इन करें और विश्लेषण करें कि कौन से लोग क्वेरी लॉग विश्लेषण टूल जैसे pgFouine या pqa का उपयोग करके चलाने के लिए लंबा समय ले रहे हैं। अधिक जानकारी के लिए "Logging Difficult Queries" देखें।
दूसरा दृष्टिकोण pg_stat_user_tables पर देखना है और उन तालिकाओं को देखना है जिनके पास बड़ी संख्या में अनुक्रमिक स्कैन हैं, जहां seq_tup_fetch बड़ा है। जब एक इंडेक्स का उपयोग किया जाता है तो idx_fetch_tup गिनती इसके बजाय बढ़ जाती है। यह आपको तब तक जोड़ सकता है जब किसी तालिका को इसके खिलाफ प्रश्नों के उत्तर देने के लिए पर्याप्त रूप से अनुक्रमित नहीं किया जाता है।
असल में यह पता लगाने के लिए कि आपको किन कॉलम पर इंडेक्स करना चाहिए? वह आम तौर पर फिर से क्वेरी लॉग विश्लेषण सामग्री की ओर जाता है।
PoWA PostgreSQL 9.4+ के लिए एक दिलचस्प टूल की तरह लगता है। यह आंकड़े एकत्र करता है, उन्हें कल्पना करता है, और सूचकांक सुझाता है। यह pg_stat_statements एक्सटेंशन का उपयोग करता है।
PoWA PostgreSQL वर्कलोड विश्लेषक है जो प्रदर्शन आंकड़े एकत्र करता है और आपके PostgreSQL सर्वरों की निगरानी और ट्यून करने में सहायता के लिए रीयल-टाइम चार्ट और ग्राफ़ प्रदान करता है। यह ओरेकल एडब्लूआर या एसक्यूएल सर्वर एमडीडब्ल्यू के समान है।
PostgreSQL का विश्लेषण करने के लिए एक और नया और दिलचस्प टूल PgHero है। यह डेटाबेस को ट्यून करने पर अधिक केंद्रित है और कई विश्लेषण और सुझाव देता है।
आप सूचकांक के उपयोग और सूचकांक आकार को खोजने के लिए क्वेरी के नीचे का उपयोग कर सकते हैं:
Reference is taken from this blog.
SELECT
pt.tablename AS TableName
,t.indexname AS IndexName
,pc.reltuples AS TotalRows
,pg_size_pretty(pg_relation_size(quote_ident(pt.tablename)::text)) AS TableSize
,pg_size_pretty(pg_relation_size(quote_ident(t.indexrelname)::text)) AS IndexSize
,t.idx_scan AS TotalNumberOfScan
,t.idx_tup_read AS TotalTupleRead
,t.idx_tup_fetch AS TotalTupleFetched
FROM pg_tables AS pt
LEFT OUTER JOIN pg_class AS pc
ON pt.tablename=pc.relname
LEFT OUTER JOIN
(
SELECT
pc.relname AS TableName
,pc2.relname AS IndexName
,psai.idx_scan
,psai.idx_tup_read
,psai.idx_tup_fetch
,psai.indexrelname
FROM pg_index AS pi
JOIN pg_class AS pc
ON pc.oid = pi.indrelid
JOIN pg_class AS pc2
ON pc2.oid = pi.indexrelid
JOIN pg_stat_all_indexes AS psai
ON pi.indexrelid = psai.indexrelid
)AS T
ON pt.tablename = T.TableName
WHERE pt.schemaname='public'
ORDER BY 1;
तो यह है। थोड़ी देर में इसे देखा नहीं है। मेरे स्वीकृत उत्तर को अपडेट किया गया। – Cerin