tl;dr आपको item_id . पर एक इंडेक्स जोड़ना होगा . Postgres अनुक्रमण का "काला जादू" 11 में शामिल है। अनुक्रमणिका
।
आपके पास (topic_id, item_id) . पर एक संयुक्त अनुक्रमणिका है और कॉलम ऑर्डर महत्वपूर्ण है। पोस्टग्रेज़ इसका उपयोग topic_id . पर प्रश्नों को अनुक्रमित करने के लिए कर सकते हैं , दोनों topic_id . पर क्वेरीज़ और item_id , लेकिन नहीं (या कम कुशलता से) item_id अकेले।
11.3.1 से बहुस्तंभ अनुक्रमणिका ...
-- indexed
select *
from topics_items
where topic_id = ?
-- also indexed
select *
from topics_items
where topic_id = ?
and item_id = ?
-- probably not indexed
select *
from topics_items
where item_id = ?
ऐसा इसलिए है क्योंकि एक समग्र अनुक्रमणिका जैसे (topic_id, item_id) पहले विषय आईडी संग्रहीत करता है, फिर एक आइटम आईडी जिसमें वह विषय आईडी भी होता है। इस इंडेक्स में किसी आइटम आईडी को कुशलता से देखने के लिए, पोस्टग्रेज़ को पहले विषय आईडी के साथ खोज को सीमित करना होगा।
पोस्टग्रेज कर सकते हैं एक इंडेक्स को उलट दें अगर उसे लगता है कि यह प्रयास के लायक है। यदि संभावित विषय आईडी की एक छोटी संख्या है, और बड़ी संख्या में संभावित इंडेक्स आईडी हैं, तो यह प्रत्येक विषय आईडी में इंडेक्स आईडी की खोज करेगा।
उदाहरण के लिए, मान लें कि आपके पास 10 संभावित विषय आईडी और 1000 संभावित आइटम आईडी हैं और आपकी अनुक्रमणिका (topic_id, index_id) है . यह 10 स्पष्ट रूप से लेबल किए गए विषय आईडी बकेट की तरह है, जिनमें से प्रत्येक में 1000 स्पष्ट रूप से लेबल किए गए आइटम आईडी बकेट हैं। आइटम आईडी बकेट तक पहुंचने के लिए, इसे प्रत्येक विषय आईडी बकेट के अंदर देखना होगा। where item_id = 23 . पर इस इंडेक्स का इस्तेमाल करने के लिए पोस्टग्रेज़ को आइटम आईडी 23 के साथ सभी बकेट के लिए 10 विषय आईडी बकेट में से प्रत्येक को खोजना होगा।
लेकिन अगर आपके पास 1000 संभावित विषय आईडी और 10 संभावित आइटम आईडी हैं, तो पोस्टग्रेस को 1000 विषय आईडी बाल्टी खोजना होगा। सबसे अधिक संभावना है कि यह इसके बजाय एक पूर्ण टेबल स्कैन करेगा। इस मामले में आप अपनी अनुक्रमणिका को उलटना चाहते हैं और इसे (item_id, topic_id) बनाना चाहते हैं ।
यह बहुत हद तक अच्छे तालिका आँकड़े होने पर निर्भर करता है, जिसका अर्थ है कि यह सुनिश्चित करना कि ऑटोवैक्यूम ठीक से काम कर रहा है।
तो आप दो स्तंभों के लिए एकल अनुक्रमणिका से दूर हो सकते हैं, यदि एक स्तंभ में दूसरे की तुलना में बहुत कम परिवर्तनशीलता है।
Postgres मल्टीपल इंडेक्स का भी उपयोग कर सकता है यदि उसे लगता है कि यह क्वेरी को चलाएगा तेज़
. उदाहरण के लिए, यदि आपके पास topic_id . पर एक अनुक्रमणिका है और item_id . पर एक इंडेक्स , यह कर सकता है दोनों इंडेक्स का उपयोग करें और परिणामों को गठबंधन करें। उदाहरण के लिए where topic_id = 23 or item_id = 42 विषय आईडी 23 खोजने के लिए विषय_आईडी अनुक्रमणिका का उपयोग कर सकता है, और आइटम आईडी 42 को खोजने के लिए आइटम_आईडी अनुक्रमणिका का उपयोग कर सकता है, फिर परिणामों को संयोजित कर सकता है।
यह आमतौर पर एक समग्र (topic_id, item_id) . होने की तुलना में धीमा है अनुक्रमणिका। यह एकल अनुक्रमणिका का उपयोग करने की तुलना में धीमा भी हो सकता है, इसलिए यदि Postgres एकाधिक अनुक्रमणिका का उपयोग नहीं करने का निर्णय लेता है तो आश्चर्यचकित न हों।
सामान्य तौर पर, बी-ट्री इंडेक्स के लिए, जब आपके पास दो कॉलम होते हैं तो आपके पास तीन संभावित संयोजन होते हैं।
- ए + बी
- ए
- ख
और आपको दो इंडेक्स चाहिए।
- (a, b) -- a और a + b
- (b) -- b
(a, b) ए और ए + बी दोनों खोजों को शामिल करता है। (b) b . की खोज के लिए कवर ।
जब आपके पास तीन कॉलम होते हैं, तो आपके पास सात संभावित संयोजन होते हैं।
- ए + बी + सी
- ए + बी
- ए + सी
- ए
- बी + सी
- ख
- सी
लेकिन आपको केवल तीन इंडेक्स चाहिए।
- (a, b, c) -- a, a + b, a + b + c
- (b, c) -- b, b + c
- (c, a) -- c, c + a
हालांकि, आप शायद वास्तव में तीन कॉलम पर एक इंडेक्स रखने से बचना चाहते हैं। यह अक्सर धीमा होता है . आप वास्तव में यही चाहते हैं।
- (ए, बी)
- (बी, सी)
- (सी, ए)
एक इंडेक्स से पढ़ना टेबल से पढ़ने की तुलना में धीमा है। आप चाहते हैं कि आपकी अनुक्रमणिका उन पंक्तियों की संख्या को कम करें जिन्हें पढ़ा जाना चाहिए, लेकिन आप नहीं चाहते कि Postgres को आवश्यकता से अधिक अनुक्रमणिका स्कैनिंग करनी पड़े।
