पोस्टग्रेज टाइमस्टैम्प क्वेरी रेंज को ऑप्टिमाइज़ करें

CLUSTER

यदि आप CLUSTER . का उपयोग करना चाहते हैं , प्रदर्शित सिंटैक्स अमान्य है।

<स्ट्राइक>create CLUSTER ticket USING ticket_1_idx;

एक बार दौड़ें:

CLUSTER ticket USING ticket_1_idx;

यह कर सकते हैं बड़े परिणाम सेट के साथ बहुत मदद करें। लौटाई गई एक भी पंक्ति के लिए इतना अधिक नहीं है। यदि आपकी तालिका केवल-पढ़ने के लिए नहीं है, तो समय के साथ प्रभाव बिगड़ता है और आपको कुछ निश्चित अंतरालों पर फिर से चलाने की आवश्यकता होती है:

CLUSTER ticket;

संभवतः केवल अस्थिर विभाजन पर। नीचे देखें।

हालांकि , यदि आपके पास बहुत सारे अपडेट हैं, CLUSTER (या VACUUM FULL ) वास्तव में प्रदर्शन के लिए खराब हो सकता है। ब्लोट की सही मात्रा UPDATE की अनुमति देती है एक ही डेटा पृष्ठ पर नए पंक्ति संस्करण रखने के लिए और ओएस में अंतर्निहित फ़ाइल को भौतिक रूप से विस्तारित करने की आवश्यकता से बचा जाता है। आप सावधानीपूर्वक ट्यून किए गए FILLFACTOR . का उपयोग कर सकते हैं दोनों दुनियाओं में सर्वश्रेष्ठ पाने के लिए:

• एक अनुक्रमिक अनुक्रमणिका के लिए कारक भरें जो PK है

pg_repack

CLUSTER टेबल पर एक विशेष लॉक लेता है, जो एक बहु-उपयोगकर्ता वातावरण में एक समस्या हो सकती है। मैनुअल को उद्धृत करना:

जब एक टेबल को क्लस्टर किया जा रहा हो, तो एक ACCESS EXCLUSIVE उस पर ताला लगा है। यह किसी भी अन्य डेटाबेस संचालन को रोकता है (दोनों पढ़ते और लिखते हैं ) टेबल पर काम करने से लेकर CLUSTER . तक समाप्त हो गया है।

बोल्ड जोर मेरा। वैकल्पिक pg_repack . पर विचार करें :

CLUSTER के विपरीत और VACUUM FULL यह प्रोसेसिंग के दौरान प्रोसेस्ड टेबल पर बिना किसी एक्सक्लूसिव लॉक के ऑनलाइन काम करता है। pg_repack बूट करने के लिए कुशल है, प्रदर्शन के साथ CLUSTER . का उपयोग करने के लिए तुलनीय है सीधे।

और:

पुनर्गठन के अंत में pg_repack को एक विशेष लॉक लेने की आवश्यकता है।

संस्करण 1.3.1 इसके साथ काम करता है:

पोस्टग्रेएसक्यूएल 8.3, 8.4, 9.0, 9.1, 9.2, 9.3, 9.4

संस्करण 1.4.2 इसके साथ काम करता है:

PostgreSQL 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 10

क्वेरी

क्वेरी इतनी सरल है कि प्रति प्रदर्शन कोई समस्या उत्पन्न नहीं होती है।

हालांकि, सटीकता . पर एक शब्द :BETWEEN निर्माण शामिल है सीमाओं। आपकी क्वेरी 19 दिसंबर, प्लस . को चुनती है 20 दिसंबर, 00:00 बजे से रिकॉर्ड। यह एक अत्यंत असंभव है मांग। संभावना है, आप वास्तव में चाहते हैं:

SELECT *
FROM   ticket 
WHERE  created >= '2012-12-19 0:0'
AND    created <  '2012-12-20 0:0';

प्रदर्शन

सबसे पहले, आप पूछें:

यह अनुक्रमिक स्कैन का चयन क्यों कर रहा है?

आपका EXPLAIN आउटपुट स्पष्ट रूप से एक इंडेक्स स्कैन . दिखाता है , अनुक्रमिक तालिका स्कैन नहीं। जरूर किसी तरह की गलतफहमी हुई होगी।

यदि आप पर बेहतर प्रदर्शन के लिए बहुत दबाव डाला जाता है, तो आप चीजों में सुधार करने में सक्षम हो सकते हैं। लेकिन आवश्यक पृष्ठभूमि की जानकारी प्रश्न में नहीं है। संभावित विकल्पों में शामिल हैं:

• आप * . के बजाय केवल आवश्यक कॉलम पूछ सकते हैं स्थानांतरण लागत (और संभवतः अन्य प्रदर्शन लाभ) को कम करने के लिए।

• आप विभाजन . देख सकते हैं और व्यावहारिक समय के टुकड़ों को अलग-अलग तालिकाओं में रखें। आवश्यकतानुसार विभाजन में अनुक्रमणिका जोड़ें।

• यदि विभाजन एक विकल्प नहीं है, तो एक या अधिक आंशिक अनुक्रमणिका जोड़ने के लिए एक अन्य संबंधित लेकिन कम दखल देने वाली तकनीक होगी .
  उदाहरण के लिए, यदि आप अधिकतर चालू माह . को क्वेरी करते हैं , आप निम्न आंशिक अनुक्रमणिका बना सकते हैं:

  CREATE INDEX ticket_created_idx ON ticket(created)
  WHERE created >= '2012-12-01 00:00:00'::timestamp;
  

  CREATE एक नई अनुक्रमणिका ठीक पहले एक नए महीने की शुरुआत। आप क्रॉन जॉब के साथ आसानी से कार्य को स्वचालित कर सकते हैं। वैकल्पिक रूप से DROP पुराने महीनों के लिए आंशिक अनुक्रमणिका बाद में।

• CLUSTER . के लिए कुल अनुक्रमणिका को अतिरिक्त रखें (जो आंशिक इंडेक्स पर काम नहीं कर सकता)। यदि पुराने रिकॉर्ड कभी नहीं बदलते हैं, तो तालिका विभाजन इस कार्य में बहुत मदद करेगा, क्योंकि आपको केवल नए विभाजनों को फिर से क्लस्टर करने की आवश्यकता है। फिर यदि रिकॉर्ड कभी नहीं बदलते हैं, तो आपको शायद CLUSTER की आवश्यकता नहीं है। ।

यदि आप अंतिम दो चरणों को मिलाते हैं, तो प्रदर्शन शानदार होना चाहिए।

प्रदर्शन मूल बातें

हो सकता है कि आप मूलभूत बातों में से एक को याद कर रहे हों। सभी सामान्य प्रदर्शन सलाह लागू होती हैं:

• https://wiki.postgresql.org/wiki/Slow_Query_Questions
• https://wiki.postgresql.org/wiki/Performance_Optimization