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

फूल

सामान्य अवधारणा

एक शास्त्रीय ब्लूम फ़िल्टर एक डेटा संरचना है जो हमें एक सेट में एक तत्व की सदस्यता की जल्दी से जांच करने में सक्षम बनाता है। फ़िल्टर अत्यधिक कॉम्पैक्ट है, लेकिन गलत सकारात्मकता की अनुमति देता है: यह गलती से किसी तत्व को सेट का सदस्य (गलत सकारात्मक) मान सकता है, लेकिन इसे सेट के एक तत्व पर विचार करने की अनुमति नहीं है (झूठी नकारात्मक) ।

फ़िल्टर एक सरणी है

$एम$ बिट्स (जिसे एक हस्ताक्षर भी कहा जाता है) जो शुरू में शून्य से भरा होता है।

$k$ अलग-अलग हैश फ़ंक्शंस चुने गए हैं जो सेट के किसी भी तत्व को मैप करते हैं

$k$ हस्ताक्षर के टुकड़े। सेट में एक तत्व जोड़ने के लिए, हमें हस्ताक्षर में इनमें से प्रत्येक बिट को सेट करना होगा। नतीजतन, यदि तत्व के अनुरूप सभी बिट्स एक पर सेट होते हैं, तो तत्व सेट का सदस्य हो सकता है, लेकिन यदि कम से कम एक बिट शून्य के बराबर होता है, तो तत्व निश्चित रूप से सेट में नहीं है।

एक DBMS के मामले में, हमारे पास वास्तव में है

$एन$ प्रत्येक इंडेक्स पंक्ति के लिए अलग से फ़िल्टर बनाया गया। एक नियम के रूप में, कई क्षेत्रों को सूचकांक में शामिल किया गया है, और यह इन क्षेत्रों का मान है जो प्रत्येक पंक्ति के लिए तत्वों के सेट की रचना करते हैं।

हस्ताक्षर की लंबाई का चयन करके

$एम$ , हम सूचकांक आकार और झूठी सकारात्मकता की संभावना के बीच एक व्यापार बंद पा सकते हैं। ब्लूम इंडेक्स के लिए आवेदन क्षेत्र बड़ा है, काफी "विस्तृत" तालिकाओं को प्रत्येक फ़ील्ड पर फिल्टर का उपयोग करके क्वेरी किया जाना है। BRIN की तरह, इस एक्सेस विधि को अनुक्रमिक स्कैन के त्वरक के रूप में माना जा सकता है: सूचकांक द्वारा पाए जाने वाले सभी मैचों को तालिका के साथ पुन: जांचना होगा, लेकिन अधिकांश पंक्तियों पर विचार करने से बचने का एक मौका है।

संरचना

हमने पहले ही GiST पहुंच विधि के संदर्भ में हस्ताक्षर पेड़ों पर चर्चा की है। इन पेड़ों के विपरीत, ब्लूम सूचकांक एक सपाट संरचना है। इसमें अनुक्रमणिका पंक्तियों के साथ नियमित पृष्ठों के बाद एक मेटापेज होता है। प्रत्येक सूचकांक पंक्ति में एक तालिका पंक्ति (TID) के हस्ताक्षर और संदर्भ होते हैं, जैसा कि चित्र में दिखाया गया है।

पैरामीटर मानों का निर्माण और विकल्प

ब्लूम इंडेक्स बनाते समय, हस्ताक्षर का कुल आकार ("लंबाई") निर्दिष्ट किया जाता है, साथ ही सूचकांक में शामिल प्रत्येक व्यक्तिगत क्षेत्र के लिए सेट किए जाने वाले बिट्स की संख्या ("col1" - "col32"):

create index on ... using bloom(...) with (length=..., col1=..., col2=..., ...);

बिट्स की संख्या निर्दिष्ट करने का तरीका अजीब लगता है: इन नंबरों को इंडेक्स के बजाय एक ऑपरेटर वर्ग के पैरामीटर होने चाहिए। बात यह है कि वर्तमान में ऑपरेटर कक्षाएं पैरामीट्रिक नहीं हो सकती हैं, हालांकि इस पर काम चल रहा है।

दुर्भाग्य से, इस पर आगे कोई प्रगति नहीं हुई है।

हम उपयुक्त मूल्यों को कैसे चुन सकते हैं? सिद्धांत बताता है कि संभावना दी

$पी$ एक झूठी सकारात्मक वापस करने के लिए एक फिल्टर, हस्ताक्षर बिट्स की इष्टतम संख्या के रूप में अनुमान लगाया जा सकता है

$m = nn \ log_2 p / \ ln 2$ , कहाँ

$एन$ सूचकांक में फ़ील्ड की संख्या और सेट की जाने वाली बिट्स की संख्या है

$k = - \ log_2 p$ ।

हस्ताक्षर को दो-बाइट पूर्णांक संख्याओं के एक सरणी के रूप में सूचकांक के अंदर संग्रहीत किया जाता है, इसलिए इसका मान

$एम$ सुरक्षित रूप से गोल किया जा सकता है

$16$ ।

संभावना चुनते समय

$पी$ , हमें सूचकांक के आकार को ध्यान में रखना होगा, जो लगभग बराबर होगा

$(एम / 8 + 6) एन$ , कहाँ

$एन$ तालिका में पंक्तियों की संख्या और है

$6$ बाइट्स में TID पॉइंटर का आकार है।

नोट करने के लिए कुछ बिंदु:

संभावना $पी$ एक झूठी सकारात्मक एक फिल्टर से संबंधित है, इसलिए, हम प्राप्त करने की उम्मीद करते हैं $एनपी$ तालिका स्कैन के दौरान झूठी सकारात्मकता (निश्चित रूप से, कुछ पंक्तियों को लौटाने वाली क्वेरी के लिए)। उदाहरण के लिए, एक मिलियन पंक्तियों वाली तालिका और प्रायिकता 0.01, क्वेरी प्लान में, औसतन, हम "इंडेक्स रीचेक द्वारा रीव्स रिमूव्ड: 10000" उम्मीद कर सकते हैं।
ब्लूम फ़िल्टर एक संभाव्य संरचना है। यह केवल विशिष्ट संख्याओं की बात करने के लिए समझ में आता है जब बहुत सारे मूल्यों का औसत होता है, जबकि प्रत्येक विशेष मामले में, हम जो कुछ भी सोच सकते हैं वह प्राप्त कर सकते हैं।
उपरोक्त अनुमान एक आदर्श गणितीय मॉडल और कुछ मान्यताओं पर आधारित हैं। व्यवहार में, परिणाम खराब होने की संभावना है। इसलिए, फार्मूले को न समझें: वे केवल भविष्य के प्रयोगों के लिए प्रारंभिक मूल्यों को चुनने के लिए एक साधन हैं।
प्रत्येक क्षेत्र के लिए व्यक्तिगत रूप से, एक्सेस विधि हमें सेट किए जाने वाले बिट की संख्या चुनने में सक्षम बनाती है। एक उचित धारणा है कि वास्तव में इष्टतम संख्या कॉलम में मूल्यों के वितरण पर निर्भर करती है। गोता लगाने के लिए, आप इस लेख को पढ़ सकते हैं (अन्य शोधों के संदर्भ स्वागत योग्य हैं)। लेकिन पहले पिछले आइटम को फिर से भरें।

अद्यतन कर रहा है

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

एक नियमित ब्लूम फ़िल्टर तत्वों को हटाने का समर्थन नहीं करता है, लेकिन ब्लूम सूचकांक के लिए इसकी आवश्यकता नहीं है: जब एक तालिका पंक्ति हटा दी जाती है, तो पूरे हस्ताक्षर को हटा दिया जाता है, साथ ही सूचकांक पंक्ति भी।

हमेशा की तरह, एक अपडेट में पुराने पंक्ति संस्करण को हटाने और नए एक के सम्मिलन (खरोंच से गणना की जा रही हस्ताक्षर) शामिल हैं।

स्कैनिंग

चूंकि केवल एक चीज जो ब्लूम फ़िल्टर कर सकती है वह एक सेट में किसी तत्व की सदस्यता की जांच करना है, ब्लूम इंडेक्स द्वारा समर्थित एकमात्र ऑपरेशन एक इक्विटी चेक (जैसे हैश इंडेक्स) है।

जैसा कि हमने पहले ही उल्लेख किया है, ब्लूम इंडेक्स सपाट है, इसलिए इंडेक्स एक्सेस के दौरान, इसे हमेशा क्रमिक रूप से और पूरी तरह से पढ़ा जाता है। पढ़ने के दौरान, एक बिटमैप का निर्माण होता है, जो तब तालिका तक पहुंचने के लिए उपयोग किया जाता है।

एक नियमित सूचकांक एक्सेस में, यह माना जाता है कि कुछ सूचकांक पंक्तियों को पढ़ना होगा और इसके अलावा, उन्हें जल्द ही फिर से आवश्यक हो सकता है, इसलिए, उन्हें एक बफर कैश में संग्रहीत किया जाता है। ब्लूम इंडेक्स का पढ़ना, वास्तव में एक अनुक्रमिक स्कैन है। कैश से उपयोगी जानकारी निकालने से रोकने के लिए, पढ़ना एक छोटे बफर रिंग के माध्यम से किया जाता है, ठीक उसी तरह जैसे तालिकाओं के अनुक्रमिक स्कैन के लिए।

हमें यह ध्यान रखना चाहिए कि ब्लूम इंडेक्स का आकार जितना अधिक होगा, यह योजनाकार को उतना ही कम आकर्षक लगेगा। यह निर्भरता रैखिक है, पेड़ की तरह अनुक्रमित के विपरीत।

उदाहरण

तालिका

चलो पिछले लेख से एक बड़ी "फ्लाइट्स_बी" तालिका के उदाहरण से ब्लूम इंडेक्स को देखते हैं। आपको याद दिलाने के लिए, लगभग 30 मिलियन पंक्तियों के साथ इस तालिका का आकार 4 जीबी है। तालिका की परिभाषा:

 demo=# \d flights_bi

  Table "bookings.flights_bi" Column | Type | Collation | Nullable | Default --------------------+--------------------------+-----------+----------+--------- airport_code | character(3) | | | airport_coord | point | | | airport_utc_offset | interval | | | flight_no | character(6) | | | flight_type | text | | | scheduled_time | timestamp with time zone | | | actual_time | timestamp with time zone | | | aircraft_code | character(3) | | | seat_no | character varying(4) | | | fare_conditions | character varying(10) | | | passenger_id | character varying(20) | | | passenger_name | text | | |

आइए सबसे पहले विस्तार करें: हालांकि ब्लूम इंडेक्स को 9.6 संस्करण के साथ शुरू होने वाले एक मानक वितरण में शामिल किया गया है, यह डिफ़ॉल्ट रूप से उपलब्ध नहीं है।

 demo=# create extension bloom;

पिछली बार हम BRIN ("शेड्यूल_टाइम", "वास्तविक_टाइम", "एयरपोर्ट_टॉक_ऑफ़सेट") का उपयोग करके तीन क्षेत्रों को अनुक्रमित कर सकते थे। चूंकि ब्लूम इंडेक्स डेटा के भौतिक क्रम पर निर्भर नहीं करते हैं, आइए इंडेक्स में तालिका के लगभग सभी क्षेत्रों को शामिल करने का प्रयास करें। चलो हालांकि समय क्षेत्रों ("निर्धारित_ समय" और "वास्तविक_ समय") को बाहर रखें: विधि केवल समानता के लिए तुलना का समर्थन करती है, लेकिन सटीक समय के लिए एक क्वेरी शायद ही किसी के लिए दिलचस्प है (हम, हालांकि, एक अभिव्यक्ति पर सूचकांक का निर्माण कर सकते हैं, गोल कर सकते हैं) एक दिन का समय, लेकिन हम ऐसा नहीं करेंगे)। हमें हवाई अड्डों ("एयरपोर्ट_कोर्ड") के भौगोलिक निर्देशांक को भी बाहर करना होगा: आगे की ओर देखते हुए, "बिंदु" प्रकार समर्थित नहीं है।

पैरामीटर मानों को चुनने के लिए, आइए 0.01 तक झूठी सकारात्मक की संभावना निर्धारित करें (ध्यान में रखते हुए कि वास्तव में हम अधिक प्राप्त करेंगे)। के लिए उपरोक्त सूत्र

$n = 9$ और

$N = 30 \, 000 \, $ 00$ 96 बिट का हस्ताक्षर आकार दें और प्रति तत्व 7 बिट सेट करने का सुझाव दें। सूचकांक का अनुमानित आकार 515 एमबी (तालिका का लगभग एक आठवां) है।

(16 बिट्स के न्यूनतम हस्ताक्षर आकार के साथ, सूत्र सूचकांक आकार का वादा करते हैं जो दो गुना छोटा है, लेकिन केवल 0.5 की संभावना पर भरोसा करने की अनुमति देता है, जो बहुत खराब है।)

संचालक वर्ग

तो, इंडेक्स बनाने की कोशिश करते हैं।

 demo=# create index flights_bi_bloom on flights_bi using bloom(airport_code, airport_utc_offset, flight_no, flight_type, aircraft_code, seat_no, fare_conditions, passenger_id, passenger_name) with (length=96, col1=7, col2=7, col3=7, col4=7, col5=7, col6=7, col7=7, col8=7, col9=7);

 ERROR: data type character has no default operator class for access method "bloom" HINT: You must specify an operator class for the index or define a default operator class for the data type.

दुर्भाग्य से, विस्तार हमें केवल दो ऑपरेटर कक्षाएं प्रदान करता है:

 demo=# select opcname, opcintype::regtype from pg_opclass where opcmethod = (select oid from pg_am where amname = 'bloom') order by opcintype::regtype::text;

  opcname | opcintype ----------+----------- int4_ops | integer text_ops | text (2 rows)

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

 demo=# select distinct opc.opcintype::regtype::text, amop.amopopr::regoperator, ampr.amproc from pg_am am, pg_opclass opc, pg_amop amop, pg_amproc ampr where am.amname = 'hash' and opc.opcmethod = am.oid and amop.amopfamily = opc.opcfamily and amop.amoplefttype = opc.opcintype and amop.amoprighttype = opc.opcintype and ampr.amprocfamily = opc.opcfamily and ampr.amproclefttype = opc.opcintype order by opc.opcintype::regtype::text;

  opcintype | amopopr | amproc -----------+----------------------+-------------- abstime | =(abstime,abstime) | hashint4 aclitem | =(aclitem,aclitem) | hash_aclitem anyarray | =(anyarray,anyarray) | hash_array anyenum | =(anyenum,anyenum) | hashenum anyrange | =(anyrange,anyrange) | hash_range ...

हम इस जानकारी का उपयोग करके दो गुम कक्षाएं बनाएंगे:

 demo=# CREATE OPERATOR CLASS character_ops DEFAULT FOR TYPE character USING bloom AS OPERATOR 1 =(character,character), FUNCTION 1 hashbpchar; demo=# CREATE OPERATOR CLASS interval_ops DEFAULT FOR TYPE interval USING bloom AS OPERATOR 1 =(interval,interval), FUNCTION 1 interval_hash;

एक हैश फ़ंक्शन को बिंदुओं ("बिंदु" प्रकार) के लिए परिभाषित नहीं किया गया है, और यह इस कारण से है कि हम ऐसे क्षेत्र पर ब्लूम इंडेक्स का निर्माण नहीं कर सकते हैं (जैसे हम इस प्रकार के क्षेत्रों पर हैश ज्वाइन नहीं कर सकते हैं)।

फिर से कोशिश कर रहा है:

 demo=# create index flights_bi_bloom on flights_bi using bloom(airport_code, airport_utc_offset, flight_no, flight_type, aircraft_code, seat_no, fare_conditions, passenger_id, passenger_name) with (length=96, col1=7, col2=7, col3=7, col4=7, col5=7, col6=7, col7=7, col8=7, col9=7);

 CREATE INDEX

सूचकांक का आकार 526 एमबी है, जो उम्मीद से कुछ बड़ा है। ऐसा इसलिए है क्योंकि सूत्र पृष्ठ ओवरहेड को ध्यान में नहीं रखता है।

 demo=# select pg_size_pretty(pg_total_relation_size('flights_bi_bloom'));

  pg_size_pretty ---------------- 526 MB (1 row)

प्रश्नों

अब हम विभिन्न मानदंडों का उपयोग करके खोज कर सकते हैं, और सूचकांक इसका समर्थन करेगा।

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

 demo=# explain(costs off,analyze) select * from flights_bi where passenger_name='MIROSLAV SIDOROV';

  QUERY PLAN -------------------------------------------------------------------------------------------------- Bitmap Heap Scan on flights_bi (actual time=2639.010..3010.692 rows=2 loops=1) Recheck Cond: (passenger_name = 'MIROSLAV SIDOROV'::text) Rows Removed by Index Recheck: 38562 Heap Blocks: exact=21726 -> Bitmap Index Scan on flights_bi_bloom (actual time=1065.191..1065.191 rows=38564 loops=1) Index Cond: (passenger_name = 'MIROSLAV SIDOROV'::text) Planning time: 0.109 ms Execution time: 3010.736 ms

और मारफा सोलोव्वा:

 demo=# explain(costs off,analyze) select * from flights_bi where passenger_name='MARFA SOLOVEVA';

  QUERY PLAN --------------------------------------------------------------------------------------------------- Bitmap Heap Scan on flights_bi (actual time=9980.884..10142.684 rows=2 loops=1) Recheck Cond: (passenger_name = 'MARFA SOLOVEVA'::text) Rows Removed by Index Recheck: 3950168 Heap Blocks: exact=45757 lossy=67332 -> Bitmap Index Scan on flights_bi_bloom (actual time=1037.588..1037.588 rows=212972 loops=1) Index Cond: (passenger_name = 'MARFA SOLOVEVA'::text) Planning time: 0.157 ms Execution time: 10142.730 ms

एक मामले में, फ़िल्टर ने केवल 40 हज़ार झूठी सकारात्मक और उनमें से 4 मिलियन की अनुमति दी थी दूसरे में ("इंडेक्स रीचेक द्वारा हटाए गए")। प्रश्नों का निष्पादन समय तदनुसार भिन्न होता है।

और नाम के बजाय यात्री आईडी द्वारा समान पंक्तियों को खोजने के परिणाम निम्नलिखित हैं। मिरोस्लाव:

 demo=# explain(costs off,analyze) demo-# select * from flights_bi where passenger_id='5864 006033';

  QUERY PLAN ------------------------------------------------------------------------------------------------- Bitmap Heap Scan on flights_bi (actual time=13747.305..16907.387 rows=2 loops=1) Recheck Cond: ((passenger_id)::text = '5864 006033'::text) Rows Removed by Index Recheck: 9620258 Heap Blocks: exact=50510 lossy=165722 -> Bitmap Index Scan on flights_bi_bloom (actual time=937.202..937.202 rows=426474 loops=1) Index Cond: ((passenger_id)::text = '5864 006033'::text) Planning time: 0.110 ms Execution time: 16907.423 ms

और मारफा:

 demo=# explain(costs off,analyze) select * from flights_bi where passenger_id='2461 559238';

  QUERY PLAN -------------------------------------------------------------------------------------------------- Bitmap Heap Scan on flights_bi (actual time=3881.615..3934.481 rows=2 loops=1) Recheck Cond: ((passenger_id)::text = '2461 559238'::text) Rows Removed by Index Recheck: 30669 Heap Blocks: exact=27513 -> Bitmap Index Scan on flights_bi_bloom (actual time=1084.391..1084.391 rows=30671 loops=1) Index Cond: ((passenger_id)::text = '2461 559238'::text) Planning time: 0.120 ms Execution time: 3934.517 ms

प्रभावकारिता फिर से बहुत अलग है, और इस बार मारफा अधिक भाग्यशाली था।

ध्यान दें कि एक झूठे सकारात्मक की संभावना के बाद से दो क्षेत्रों में एक साथ खोज बहुत अधिक कुशलता से की जाएगी

$पी$ में बदल जाता है

$p ^ 2$ :

 demo=# explain(costs off,analyze) select * from flights_bi where passenger_name='MIROSLAV SIDOROV' and passenger_id='5864 006033';

  QUERY PLAN -------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on flights_bi (actual time=872.593..877.915 rows=2 loops=1) Recheck Cond: (((passenger_id)::text = '5864 006033'::text) AND (passenger_name = 'MIROSLAV SIDOROV'::text)) Rows Removed by Index Recheck: 357 Heap Blocks: exact=356 -> Bitmap Index Scan on flights_bi_bloom (actual time=832.041..832.041 rows=359 loops=1) Index Cond: (((passenger_id)::text = '5864 006033'::text) AND (passenger_name = 'MIROSLAV SIDOROV'::text)) Planning time: 0.524 ms Execution time: 877.967 ms

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

ब्रिन और हैश के साथ तुलना

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

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

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

गुण

हमेशा की तरह, चलो ब्लूम के गुणों को देखें (प्रश्न पहले ही प्रदान किए जा चुके हैं )।

निम्नलिखित पहुँच विधि के गुण हैं:

  amname | name | pg_indexam_has_property --------+---------------+------------------------- bloom | can_order | f bloom | can_unique | f bloom | can_multi_col | t bloom | can_exclude | f

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

निम्नलिखित सूचकांक-परत गुण उपलब्ध हैं:

  name | pg_index_has_property ---------------+----------------------- clusterable | f index_scan | f bitmap_scan | t backward_scan | f

केवल उपलब्ध स्कैन तकनीक बिटमैप स्कैन है। चूंकि सूचकांक हमेशा पूरी तरह से स्कैन किया जाता है, इसलिए टीआईडी द्वारा पंक्तियों को वापस करने वाले नियमित सूचकांक एक्सेस को लागू करने का कोई मतलब नहीं है।

  name | pg_index_column_has_property --------------------+------------------------------ asc | f desc | f nulls_first | f nulls_last | f orderable | f distance_orderable | f returnable | f search_array | f search_nulls | f

केवल डैश यहां हैं; विधि NULLs में हेरफेर भी नहीं कर सकती है।

और अंत में:

यह असंभव नहीं है कि लेखों की यह श्रृंखला भविष्य में जारी रहेगी, जब नए सूचकांक प्रकार के ब्याज दिखाई देते हैं, लेकिन अब इसे रोकने का समय है।

मैं ड्राफ्ट पढ़ने और अपनी टिप्पणी प्रदान करने के लिए पोस्टग्रेज प्रोफेशनल (उनमें से कुछ चर्चा के कई अभिगम तरीकों के लेखक हैं) से अपने सहयोगियों की सराहना करना चाहता हूं। और, मैं निश्चित रूप से आपके धैर्य और मूल्यवान टिप्पणियों के लिए आपका आभारी हूं। आपके ध्यान ने मुझे इस मुकाम तक पहुंचने के लिए प्रोत्साहित किया। धन्यवाद!

PostgreSQL में सूचकांक - 10 (ब्लूम)

फूल