जीएसटी के लिए अनुक्रमणिका को कवर करें

कवरिंग इंडेक्स केवल एक और विशेषता नहीं है जो काम में आ सकता है। यह बात पूरी तरह से व्यावहारिक है। उनके बिना, केवल इंडेक्स स्कैन एक जीत नहीं दे सकता है। हालांकि अलग-अलग स्थितियों में कवरिंग इंडेक्स अलग-अलग तरीकों से प्रभावी होता है।

यह वास्तव में इंडेक्स को कवर करने के बारे में नहीं है: सख्ती से बोलना, पोस्टग्रेस में तथाकथित समावेशी इंडेक्स दिखाई दिए हैं। लेकिन, क्रम में: एक कवरिंग इंडेक्स एक ऐसा इंडेक्स है जिसमें क्वेरी द्वारा आवश्यक सभी कॉलम मान शामिल होते हैं; हालाँकि, तालिका तक पहुँच की अब आवश्यकता नहीं है। लगभग। आप "लगभग" और Yegor Rogov के एक लेख में अन्य बारीकियों के बारे में पढ़ सकते हैं , जो कि 10 (!) भागों की उनकी श्रंखला श्रृंखला में शामिल है। और समावेशी सूचकांक विशेष रूप से विशिष्ट प्रश्नों पर खोज के लिए बनाया गया है: जिन क्षेत्रों के खोज नहीं किए जा सकते हैं उनके मूल्यों को खोज सूचकांक में जोड़ा जाता है, उन्हें केवल इसलिए आवश्यक है ताकि तालिका को फिर से संदर्भित न किया जाए। इस तरह के इंडेक्स INCLUDE कीवर्ड के साथ बनते हैं।

अनास्तासिया लुबेनीकोवा (पोस्टग्रेज़ प्रोफेशनल) ने बीटीआरआई पद्धति को अंतिम रूप दिया ताकि सूचकांक में अतिरिक्त स्तंभों को शामिल किया जा सके। इस पैच को PostgreSQL 11. में शामिल किया गया था, लेकिन GiST / SP-GiST पहुँच विधियों के लिए पैच में इस संस्करण के रिलीज़ होने से पहले परिपक्व होने का समय नहीं था। 12 वें तक जीएसटी लागू हो गया।

GiST के लिए समावेशी अनुक्रमित करने की रचनात्मक इच्छा बहुत पहले पैदा हुई: एंड्री बोरोडिन द्वारा एक परीक्षण पैच अप्रैल 2018 के मध्य में समुदाय को वापस करने की पेशकश की गई थी। उन्होंने सभी बुनियादी, बहुत मुश्किल काम किए।

अगस्त 2019 की शुरुआत में, अलेक्जेंडर कोरोटकोव ने कॉस्मेटिक सुधारों को जोड़ा और पैच को प्रतिबद्ध किया।

प्रदर्शन और कुछ शोध के लिए, हम 3 मिलियन आयतों का एक सेट तैयार करेंगे। उसी समय, बॉक्स प्रकार के बारे में कुछ शब्द, क्योंकि इसके साथ सभी जोड़तोड़ सहज नहीं हैं।

बॉक्स का प्रकार - अर्थात, आयत - लंबे समय से Postgres में है, इसे 2 बिंदुओं (ज्यामितीय प्रकार बिंदु) द्वारा परिभाषित किया गया है - आयत के विपरीत कोने (यानी, आयत तिरछी नहीं हो सकती है, किनारे पर लिट गई)। हम दस्तावेज़ में पढ़ते हैं: "टाइप बॉक्स के मान निम्न रूपों में से एक में लिखे गए हैं:

( ( x1 , y1 ) , ( x2 , y2 ) ) ( x1 , y1 ) , ( x2 , y2 ) x1 , y1 , x2 , y2 

व्यवहार में, आपको इस तरह लिखना होगा:

 SELECT box('1,2', '3,4'); box ------------- (3,4),(1,2) (1 row) 

सबसे पहले, Postgres हमें शीर्ष दाईं ओर शीर्ष दिखाता है, फिर नीचे बाईं ओर। अगर हम ऐसा लिखते हैं,

 SELECT box('5,2', '3,4'); box ------------- (5,4),(3,2) (1 row) 

फिर हम यह सुनिश्चित करेंगे कि पोस्टग्रेट्स उन चोटियों को न दें जो उन्होंने उसे दी थीं। उन्होंने हमारे ऊपरी बाएँ और निचले दाएँ से ऊपरी दाएँ और निचले बाएँ की गणना की। यह एक सुविधाजनक संपत्ति है जब बेतरतीब ढंग से पीढ़ी के मामले में अग्रिम में नहीं जाना जाता है - उदाहरण के लिए। अंकन '1,2', '3,4' बिंदु (1,2), बिंदु (3,4) के बराबर है। यह रूप कभी-कभी अधिक सुविधाजनक होता है।

व्यापार के लिए: 3 मिलियन आयतों में खोजें

 CREATE TABLE boxes(id serial, thebox box, name text); 

हम 3 मिलियन यादृच्छिक आयतें उत्पन्न करेंगे। हम एक सामान्य वितरण चाहते हैं, लेकिन टेबलफंक एक्सटेंशन का उपयोग नहीं करने के लिए, हम "खराब" दृष्टिकोण का उपयोग करते हैं: हम यादृच्छिक () - यादृच्छिक () का उपयोग करते हैं, जो एक अच्छी तस्वीर भी देता है (अंजीर देखें।) आयतों के साथ, केंद्र के करीब बड़ा। गुरुत्वाकर्षण के उनके केंद्र भी यादृच्छिक हैं। इस तरह के वितरण कुछ प्रकार के वास्तविक शहर डेटा की विशेषता हैं। और जो आंकड़े या ताज़ा यादों के नियमों में तल्लीन करना चाहते हैं, वे यादृच्छिक चर के अंतर के बारे में पढ़ सकते हैं, उदाहरण के लिए, यहां ।

 INSERT INTO boxes(thebox, name) SELECT box( point( random()-random(), random()-random() ), point( random()-random(), random()-random() ) ), 'box no.' || x FROM generate_series(1,3000000) AS g(x); 

तालिका का आकार जो दिखाता है कि \dt+ 242MB है। अब आप खोज शुरू कर सकते हैं।

हम एक सूचकांक के बिना देख रहे हैं:

 EXPLAIN ANALYZE SELECT thebox, name FROM boxes WHERE thebox @> box('0.5, 0.4','0.3, 0.2'); QUERY PLAN -------------------------------------------------------------------------------------- Gather (cost=1000.00..47853.00 rows=3000 width=46) (actual time=0.140..246.998 rows=139189 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on boxes (cost=0.00..46553.00 rows=1250 width=46) (actual time=0.011..106.708 rows=46396 loops=3) Filter: (thebox @> '(0.5,0.4),(0.3,0.2)'::box) Rows Removed by Filter: 953604 Planning Time: 0.040 ms Execution Time: 259.262 ms (8 rows) 

हम देखते हैं कि एक समानांतर Seq स्कैन है - अनुक्रमिक स्कैन (यद्यपि समानांतर)।

एक नियमित, गैर-समावेशी सूचकांक बनाएँ:

 CREATE INDEX ON boxes USING gist(thebox); 

boxes_thebox_idx इंडेक्स का आकार, जो \di+ , 262MB दिखाता है। उसी अनुरोध के जवाब में, हम:

 EXPLAIN ANALYZE SELECT thebox, name FROM boxes WHERE thebox @> box('0.5, 0.4','0.3, 0.2'); QUERY PLAN -------------------------------------------------------------------------------- Bitmap Heap Scan on boxes (cost=159.66..9033.30 rows=3000 width=46) (actual time=29.101..80.283 rows=139189 loops=1) Recheck Cond: (thebox @> '(0.5,0.4),(0.3,0.2)'::box) Heap Blocks: exact=30629 -> Bitmap Index Scan on boxes_thebox_idx (cost=0.00..158.91 rows=3000 width=0) (actual time=25.029..25.029 rows=139189 loops=1) Index Cond: (thebox @> '(0.5,0.4),(0.3,0.2)'::box) Planning Time: 0.053 ms Execution Time: 86.206 ms (7 rows) 

खोज का समय तीन के एक कारक से कम हो गया था, और समानांतर सीक स्कैन के बजाय, उन्हें एक बिटमैप इंडेक्स स्कैन प्राप्त हुआ। यह समानांतर नहीं है, लेकिन यह तेजी से काम करता है।

अब पुराने सूचकांक को मारें और एक समावेशी बनाएं:

 CREATE INDEX ON boxes USING spgist(thebox) INCLUDE(name); 

boxes_thebox_name_idx का boxes_thebox_name_idx : 356 एमबी। आइए जाने:

 EXPLAIN ANALYZE SELECT thebox, name FROM boxes WHERE thebox @> box('0.5, 0.4','0.3, 0.2'); QUERY PLAN ------------------------------------------------------------------------------ Bitmap Heap Scan on boxes (cost=207.66..9081.30 rows=3000 width=46) (actual time=86.822..152.014 rows=139189 loops=1) Recheck Cond: (thebox @> '(0.5,0.4),(0.3,0.2)'::box) Heap Blocks: exact=30629 -> Bitmap Index Scan on boxes_thebox_name_idx (cost=0.00..206.91 rows=3000 width=0) (actual time=83.044..83.044 rows=139189 loops=1) Index Cond: (thebox @> '(0.5,0.4),(0.3,0.2)'::box) Planning Time: 3.807 ms Execution Time: 157.997 ms (7 rows) 

इंडेक्स ओनली स्कैन का उपयोग किया जाता है, लेकिन तस्वीर दुखद है: समय इसके बिना लगभग 2 गुना लंबा है। हम सूचकांकों के निर्माता की हैंडबुक को भाग I में पढ़ते हैं:

। रंग PostgreSQL अनुक्रमित में ऐसी जानकारी नहीं होती है जो आपको पंक्तियों की दृश्यता का न्याय करने की अनुमति देती है। इसलिए, एक्सेस विधि खोज स्थिति के तहत आने वाली पंक्तियों के सभी संस्करणों को लौटा देती है, भले ही वे वर्तमान लेनदेन के लिए दिखाई दें या नहीं। हालाँकि, यदि दृश्यता निर्धारित करने के लिए अनुक्रमण तंत्र को हर बार तालिका में देखना होता है, तो यह स्कैनिंग विधि सामान्य सूचकांक स्कैनिंग से अलग नहीं होगी। समस्या इस तथ्य से हल होती है कि PostgreSQL तालिकाओं के लिए तथाकथित दृश्यता मानचित्र का समर्थन करता है, जिसमें वैक्यूम प्रक्रिया उन पृष्ठों को चिह्नित करती है जिसमें डेटा सभी लेन-देन के लिए लंबे समय तक नहीं बदला है, भले ही यह शुरुआती समय और अलगाव स्तर की परवाह किए बिना हो। यदि सूचकांक द्वारा दी गई पंक्ति की पहचानकर्ता ऐसे पृष्ठ को संदर्भित करता है, तो दृश्यता की जाँच नहीं की जा सकती है।>

हम VACUUM करते हैं। हम दोहराने:

 EXPLAIN ANALYZE SELECT thebox, name FROM boxes WHERE thebox @> box('0.5, 0.4','0.3, 0.2'); QUERY PLAN -------------------------------------------------------------------------------- Index Only Scan using boxes_thebox_name_idx on boxes (cost=0.41..236.91 rows=3000 width=46) (actual time=0.104..38.651 rows=139189 loops=1) Index Cond: (thebox @> '(0.5,0.4),(0.3,0.2)'::box) Heap Fetches: 0 Planning Time: 0.052 ms Execution Time: 44.337 ms (5 rows) 

एक पूरी तरह से अलग मामला! गैर-समावेशी सूचकांक की तुलना में दो बार लाभ।

चयनात्मकता और लाभ

समावेशी सूचकांक का प्रदर्शन प्रश्नों में परिस्थितियों की चयनात्मकता पर अत्यधिक निर्भर है। इस निर्भरता को थोड़ा जांचने के लिए, हम व्युत्क्रम समस्या को हल करेंगे: हम एक प्रकार के सूचकांक के साथ एक लेबल उत्पन्न करेंगे और हम देखेंगे कि दिए गए बॉक्स में कितने अंक गिरेंगे। समान रूप से डॉट्स फैलाएं।

 CREATE TABLE test_covergist(id serial, tochka point, name text); 

 INSERT INTO test_covergist(tochka, name) SELECT point(trunc(1000000*random()), trunc(1000000*random())), 'point no.' || gx FROM generate_series(1,3000000) AS g(x); 

तालिका का आकार 211 एमबी है।

 CREATE INDEX on test_covergist USING gist(tochka); 

आकार 213 एमबी।

हम स्पष्ट रूप से सभी उपलब्ध बिंदुओं को एक वर्ग में ले जाएंगे:

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','3000000,3000000') @> tochka; QUERY PLAN ------------------------------------------------------------------------------------- Bitmap Heap Scan on test_covergist (cost=135.66..8778.83 rows=3000 width=32) (actual time=1087.964..1864.059 rows=3000000 loops=1) Recheck Cond: ('(3000000,3000000),(0,0)'::box @> tochka) Heap Blocks: exact=27025 Buffers: shared read=54287 -> Bitmap Index Scan on test_covergist_tochka_idx (cost=0.00..134.91 rows=3000 width=0) (actual time=1084.949..1084.949 rows=3000000 loops=1) Index Cond: (tochka <@ '(3000000,3000000),(0,0)'::box) Buffers: shared read=27262 Planning Time: 0.102 ms Execution Time: 2029.501 ms (9 rows) 

हमने EXPLAIN को बफ़र्स दिखाने के लिए कहा। यह काम आएगा। अब अनुरोध निष्पादन का समय 2 सेकंड से अधिक है, यह देखा जा सकता है कि बफर: साझा पढ़ा = 54287। एक अन्य स्थिति में, हम साझा रीड और शेयर्ड हिट का मिश्रण देख सकते हैं - अर्थात, कुछ बफ़र्स डिस्क (या OS कैश से) और कुछ बफर कैश से पढ़े जाते हैं। हम तालिका और अनुक्रमित के अनुमानित आकार को जानते हैं, इसलिए हम साझा बफ़र्स सेट करके खुद की रक्षा करेंगे ताकि सब कुछ फिट हो जाए - पुनरारंभ करें विकल्प के साथ पोस्टग्रेट्स

 -o "-c shared_buffers=1GB" 

अब:

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','3000000,3000000') @> tochka; QUERY PLAN ------------------------------------------------------------------------------- Bitmap Heap Scan on test_covergist (cost=135.66..8778.83 rows=3000 width=32) (actual time=231.032..613.326 rows=3000000 loops=1) Recheck Cond: ('(3000000,3000000),(0,0)'::box @> tochka) Heap Blocks: exact=27025 Buffers: shared hit=54248 -> Bitmap Index Scan on test_covergist_tochka_idx (cost=0.00..134.91 rows=3000 width=0) (actual time=228.068..228.068 rows=3000000 loops=1) Index Cond: (tochka <@ '(3000000,3000000),(0,0)'::box) Buffers: shared hit=27223 Planning Time: 0.070 ms Execution Time: 755.915 ms (9 rows) 

अर्थात्, साझा पढ़ा गया एक साझा हिट बन गया, और समय तीन बार कम हो गया।

EXPLAIN में एक और महत्वपूर्ण विवरण: 3 मिलियन अंक लौटाए गए हैं, और रिकॉर्ड की गई संख्या का पूर्वानुमान 3 हजार है। Spoiler: यह संख्या किसी भी चयनात्मकता के साथ नहीं बदलेगी। बॉक्स या पॉइंट प्रकारों के साथ काम करने पर आशावादी को कार्डिनिटी का मूल्यांकन करने का तरीका नहीं पता है। और योजना नहीं बदलेगी: आयत के किसी भी आकार के लिए, test_covergist_tochka_idx पर एक बिटमैप इंडेक्स स्कैन होगा।

जारी किए गए रिकॉर्ड की संख्या के साथ यहां दो और माप दिए गए हैं, परिमाण के आदेशों के अनुसार भिन्न:

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','300000,300000') @> tochka; QUERY PLAN --------------------------------------------------------------------------------------- Bitmap Heap Scan on test_covergist (cost=135.66..8778.83 rows=3000 width=32) (actual time=27.889..134.054 rows=269882 loops=1) Recheck Cond: ('(300000,300000),(0,0)'::box @> tochka) Heap Blocks: exact=27024 Buffers: shared hit=29534 -> Bitmap Index Scan on test_covergist_tochka_idx (cost=0.00..134.91 rows=3000 width=0) (actual time=24.847..24.847 rows=269882 loops=1) Index Cond: (tochka <@ '(300000,300000),(0,0)'::box) Buffers: shared hit=2510 Planning Time: 0.074 ms Execution Time: 151.269 ms (9 rows) 

यह 10-विषम बार कम रिकॉर्ड (वास्तविक ... पंक्तियाँ = 269882) देता है, समय लगभग 5 गुना कम हो गया है।

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','30000,30000') @> tochka; QUERY PLAN ---------------------------------------------------------------------------------------------- Bitmap Heap Scan on test_covergist (cost=135.66..8778.83 rows=3000 width=32) (actual time=1.882..16.095 rows=2780 loops=1) Recheck Cond: ('(30000,30000),(0,0)'::box @> tochka) Heap Blocks: exact=2624 Buffers: shared hit=2655 -> Bitmap Index Scan on test_covergist_tochka_idx (cost=0.00..134.91 rows=3000 width=0) (actual time=1.035..1.035 rows=2780 loops=1) Index Cond: (tochka <@ '(30000,30000),(0,0)'::box) Buffers: shared hit=31 Planning Time: 0.154 ms Execution Time: 16.702 ms (9 rows) 

एक 30K × 30K वर्ग (2780) की सामग्री को केवल 16 एमएस में गिना जाता है। और जब दर्जनों रिकॉर्ड होते हैं, तो उन्हें पहले से ही एक एमएस के अंशों में निकाला जाता है, और ऐसे माप बहुत विश्वसनीय नहीं होते हैं।

अंत में, समावेशी सूचकांक के साथ ही मापें:

 CREATE INDEX on test_covergist USING gist(tochka) INCLUDE(name); 

साइज 316 एमबी।

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','3000000,3000000') @> tochka; QUERY PLAN --------------------------------------------------------------------------------------- Index Only Scan using test_covergist_tochka_name_idx on test_covergist (cost=0.41..216.91 rows=3000 width=32) (actual time=0.160..568.707 rows=3000000 loops=1) Index Cond: (tochka <@ '(3000000,3000000),(0,0)'::box) Heap Fetches: 0 Buffers: shared hit=40492 Planning Time: 0.090 ms Execution Time: 709.837 ms (6 rows) 

समय लगभग एक पारंपरिक सूचकांक के साथ ही है, हालांकि सूचकांक केवल स्कैन।

लेकिन:

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','300000,300000') @> tochka; QUERY PLAN -------------------------------------------------------------------------------------------- Index Only Scan using test_covergist_tochka_name_idx on test_covergist (cost=0.41..216.91 rows=3000 width=32) (actual time=0.083..53.277 rows=269882 loops=1) Index Cond: (tochka <@ '(300000,300000),(0,0)'::box) Heap Fetches: 0 Buffers: shared hit=3735 Planning Time: 0.077 ms Execution Time: 66.162 ms (6 rows) 

और यह 151 मि। और, तदनुसार:

 EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist WHERE box('0,0','300000,300000') @> tochka; QUERY PLAN -------------------------------------------------------------------------------------------- Index Only Scan using test_covergist_tochka_name_idx on test_covergist (cost=0.41..216.91 rows=3000 width=32) (actual time=0.043..0.639 rows=2780 loops=1) Index Cond: (tochka <@ '(30000,30000),(0,0)'::box) Heap Fetches: 0 Buffers: shared hit=52 Planning Time: 0.053 ms Execution Time: 0.791 ms (6 rows) 

यह पहले से ही 2780 बिंदु रिकॉर्ड के लिए एमएस का एक अंश है।

बफ़र्स को बंदूकें पसंद हैं

एक स्पष्टीकरण मांगा जा सकता है और एक शॉटगन में पाया जा सकता है जिसने अभी तक गोली नहीं ली है लेकिन वह दीवार पर लटका हुआ था: ब्लॉक की संख्या पढ़ी गई। एक समावेशी सूचकांक के मामले में, सूचकांक के केवल ब्लॉकों को ही पढ़ा जाता है (हीप फेटेक: 0)। तीन मामलों में, ये संख्या 40492, 3735 और 52 थी। लेकिन नियमित सूचकांक का उपयोग करते समय, ब्लॉक बिटमैप हीप स्कैन इंडेक्स (54248 में 3 मिलियन रिकॉर्ड) के साथ पढ़े गए बिट्स के योग को पढ़ते हैं और जिन्हें ढेर से पढ़ना पड़ता था (27223) , क्योंकि नाम क्षेत्र को एक नियमित सूचकांक से नहीं निकाला जा सकता है। 54248 + 27223 = 81471। अनन्य 40492 था। दो अन्य मामलों के लिए: 29534 + 2510 = 31044 और 2655 + 31 = 2686। एक नियमित सूचकांक के मामले में, वैसे भी अधिक ब्लॉक पढ़े जाते हैं, लेकिन चयनात्मकता में सुधार के साथ, रीड ब्लॉक की संख्या 2 गुना के बजाय परिमाण के आदेशों से भिन्न होने लगती है इस तथ्य के कारण कि ढेर ब्लॉक से आवश्यक ब्लॉक की संख्या इंडेक्स ब्लॉक को पढ़ने की तुलना में धीरे-धीरे कम हो जाती है।



लेकिन शायद बिंदु चयनात्मकता नहीं है, लेकिन केवल तालिका का आकार? बस मामले में, हम उसी चरणों को दोहराते हैं, जिसमें 300 हज़ार के साथ एक तालिका होती है, और 3 मिलियन रिकॉर्ड नहीं:

 CREATE TABLE test_covergist_small(id serial, tochka point, name text); INSERT INTO test_covergist_small(tochka, name) SELECT point(trunc(1000000*random()), trunc(1000000*random())), 'point no.' || gx FROM generate_series(1,300000) AS g(x); CREATE INDEX ON test_covergist_small USING gist(tochka); EXPLAIN (ANALYZE, buffers) SELECT tochka, name FROM test_covergist_small WHERE box('0,0','3000000,3000000') @> tochka; QUERY PLAN ---------------------------------------------------------------------------- Bitmap Heap Scan on test_covergist_small (cost=14.61..867.19 rows=300 width=31) (actual time=36.115..130.435 rows=300000 loops=1) Recheck Cond: ('(3000000,3000000),(0,0)'::box @> tochka) Heap Blocks: exact=2500 Buffers: shared hit=5225 -> Bitmap Index Scan on test_covergist_small_tochka_idx (cost=0.00..14.53 rows=300 width=0) (actual time=35.894..35.895 rows=300000 loops=1) Index Cond: (tochka <@ '(3000000,3000000),(0,0)'::box) Buffers: shared hit=2725 Planning Time: 0.060 ms Execution Time: 158.580 (9 rows) 

अगला, समावेशी सूचकांक के लिए समान दोहराएं। यहाँ परिणाम हैं:



अंकों के 100% कवरेज के मामले में, क्वेरी सामान्य सूचकांक की तुलना में थोड़ी धीमी थी। इसके अलावा, 3 मिलियन के मामले में, सब कुछ जगह में गिर गया। यही है, चयनात्मकता महत्वपूर्ण है।

मॉस्को के नक्शे पर कई मिलियन आयतों के साथ एक सेट - हमारी कंपनी ने वास्तविक डेटा पर समावेशी जीएसटी सूचकांकों का परीक्षण किया। निष्कर्ष समान है: कई स्थितियों में, इस तरह के सूचकांक प्रश्नों को स्पष्ट रूप से गति देते हैं। लेकिन लेख को चित्रों और परीक्षणों की संख्या के साथ चित्रित नहीं किया जा सकता है: यह डेटा सार्वजनिक डोमेन में नहीं है।

एक निष्कर्ष के बजाय

आइए एक पल के लिए बेतरतीब आयतों पर लौटते हैं। आइए स्पिगिस्ट के साथ भी ऐसा ही करने की कोशिश करें। आप PostgreSQL - 6 में लेख इंडेक्स पढ़कर एसपी-जीएसटी और जीएसटी के बीच के अंतर को समझ सकते हैं या याद कर सकते हैं। एक समावेशी सूचकांक बनाएँ:

 CREATE INDEX ON boxes USING spgist(thebox) INCLUDE(name); ERROR: access method "spgist" does not support included columns 

काश, SP-GiST के लिए, समावेशी सूचकांक अभी तक लागू नहीं किए गए हैं।
तो सुधार की गुंजाइश है!