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

रम

हालांकि लेखकों का दावा है कि जिन एक शक्तिशाली जिन्न है, पेय का विषय अंततः जीत गया है: अगली पीढ़ी के जिन को RUM कहा गया है।

यह पहुंच विधि GIN को समझने वाली अवधारणा को विस्तृत करती है और हमें पूर्ण-पाठ खोज को और भी तेज करने में सक्षम बनाती है। लेखों की इस श्रृंखला में, यह एकमात्र तरीका है जो मानक PostgreSQL वितरण में शामिल नहीं है और एक बाहरी विस्तार है। इसके लिए कई इंस्टॉलेशन विकल्प उपलब्ध हैं:

• PGDG रिपॉजिटरी से "yum" या "apt" पैकेज लें । उदाहरण के लिए, यदि आपने "पोस्टग्रैसिकल -10" पैकेज से पोस्टग्रेसीक्यूएल स्थापित किया है, तो "पोस्टग्रैक्कल -10-रम" भी स्थापित करें।
• जीथब पर स्रोत कोड से निर्माण करें और अपने दम पर स्थापित करें (निर्देश वहां भी है)।
• पोस्टग्रेज प्रो एंटरप्राइज के एक भाग के रूप में उपयोग करें (या कम से कम वहां से प्रलेखन पढ़ें)।

जिन की सीमाएँ

GIN की कौन सी सीमाएँ हमें RUM को पार करने में सक्षम बनाती हैं?

सबसे पहले, "tsvector" डेटा प्रकार में न केवल lexemes होते हैं, बल्कि दस्तावेज़ के अंदर उनके पदों पर भी जानकारी होती है। जैसा कि हमने पिछली बार देखा था , GIN सूचकांक इस जानकारी को संग्रहीत नहीं करता है। इस कारण से, वाक्यांशों की खोज करने के लिए ऑपरेशन, जो संस्करण 9.6 में दिखाई दिया, GIN सूचकांक द्वारा अक्षम रूप से समर्थित हैं और रीचेक के लिए मूल डेटा तक पहुंचना है।

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

पहले सन्निकटन के लिए, RUM पहुंच विधि को GIN माना जा सकता है जो अतिरिक्त रूप से स्थिति की जानकारी संग्रहीत करता है और एक आवश्यक क्रम में परिणाम वापस कर सकता है (जैसे GiST निकटतम पड़ोसियों को वापस कर सकता है)। कदम से कदम मिलाकर चलते हैं।

वाक्यांशों की खोज

एक पूर्ण-पाठ खोज क्वेरी में विशेष ऑपरेटर शामिल हो सकते हैं जो लेक्सेम के बीच की दूरी को ध्यान में रखते हैं। उदाहरण के लिए, हम उन दस्तावेजों को पा सकते हैं जिनमें "हाथ" को "जांघ" से दो और शब्दों के साथ अलग किया जाता है:

postgres=# select to_tsvector('Clap your hands, slap your thigh') @@ to_tsquery('hand <3> thigh'); 

  ?column? ---------- t (1 row) 

या हम संकेत कर सकते हैं कि शब्दों को एक के बाद एक स्थित होना चाहिए:

 postgres=# select to_tsvector('Clap your hands, slap your thigh') @@ to_tsquery('hand <-> slap'); 

  ?column? ---------- t (1 row) 

नियमित GIN इंडेक्स उन दस्तावेज़ों को वापस कर सकता है जिनमें दोनों लेक्मेम्स होते हैं, लेकिन हम केवल tvvector में देख कर उनके बीच की दूरी की जाँच कर सकते हैं:

 postgres=# select to_tsvector('Clap your hands, slap your thigh'); 

  to_tsvector -------------------------------------- 'clap':1 'hand':3 'slap':4 'thigh':6 (1 row) 

RUM इंडेक्स में, प्रत्येक lexeme केवल तालिका पंक्तियों को संदर्भित नहीं करता है: प्रत्येक TID को उन पदों की सूची के साथ प्रदान किया जाता है जहां दस्तावेज़ में lexeme होता है। इस तरह से हम "स्लिट-शीट" टेबल पर बनाए गए सूचकांक की परिकल्पना कर सकते हैं, जो पहले से ही हमारे लिए काफी परिचित है (डिफ़ॉल्ट रूप से tsvector के लिए ऑपरेटर रूम का उपयोग "रम_सैक्टर_टॉप"):

 postgres=# create extension rum; postgres=# create index on ts using rum(doc_tsv); 

आकृति में ग्रे वर्ग में स्थिति जानकारी शामिल है:

 postgres=# select ctid, left(doc,20), doc_tsv from ts; 

  ctid | left | doc_tsv -------+----------------------+--------------------------------------------------------- (0,1) | Can a sheet slitter | 'sheet':3,6 'slit':5 'slitter':4 (0,2) | How many sheets coul | 'could':4 'mani':2 'sheet':3,6 'slit':8 'slitter':7 (0,3) | I slit a sheet, a sh | 'sheet':4,6 'slit':2,8 (1,1) | Upon a slitted sheet | 'sheet':4 'sit':6 'slit':3 'upon':1 (1,2) | Whoever slit the she | 'good':7 'sheet':4,8 'slit':2 'slitter':9 'whoever':1 (1,3) | I am a sheet slitter | 'sheet':4 'slitter':5 (2,1) | I slit sheets. | 'sheet':3 'slit':2 (2,2) | I am the sleekest sh | 'ever':8 'sheet':5,10 'sleekest':4 'slit':9 'slitter':6 (2,3) | She slits the sheet | 'sheet':4 'sit':6 'slit':2 (9 rows) 

जब "फास्टअपडेट" पैरामीटर निर्दिष्ट किया जाता है तो जीआईएन एक स्थगित प्रविष्टि भी प्रदान करता है; यह कार्यक्षमता RUM से निकाल दी गई है।

यह देखने के लिए कि सूचकांक लाइव डेटा पर कैसे काम करता है, चलो pgsql-hackers मेलिंग सूची के परिचित संग्रह का उपयोग करें।

 fts=# alter table mail_messages add column tsv tsvector; fts=# set default_text_search_config = default; fts=# update mail_messages set tsv = to_tsvector(body_plain); 

 ... UPDATE 356125 

यह कैसे एक वाक्यांश है जो वाक्यांशों के लिए खोज का उपयोग करता है GIN सूचकांक के साथ किया जाता है:

 fts=# create index tsv_gin on mail_messages using gin(tsv); fts=# explain (costs off, analyze) select * from mail_messages where tsv @@ to_tsquery('hello <-> hackers'); 

  QUERY PLAN --------------------------------------------------------------------------------- Bitmap Heap Scan on mail_messages (actual time=2.490..18.088 rows=259 loops=1) Recheck Cond: (tsv @@ to_tsquery('hello <-> hackers'::text)) Rows Removed by Index Recheck: 1517 Heap Blocks: exact=1503 -> Bitmap Index Scan on tsv_gin (actual time=2.204..2.204 rows=1776 loops=1) Index Cond: (tsv @@ to_tsquery('hello <-> hackers'::text)) Planning time: 0.266 ms Execution time: 18.151 ms (8 rows) 

जैसा कि हम योजना से देख सकते हैं, GIN इंडेक्स का उपयोग किया जाता है, लेकिन यह 1776 संभावित मैच देता है, जिनमें से 259 बचे हैं और 1517 को रीचेक स्टेज पर छोड़ दिया गया है।

GIN इंडेक्स को डिलीट करते हैं और RUM का निर्माण करते हैं।

 fts=# drop index tsv_gin; fts=# create index tsv_rum on mail_messages using rum(tsv); 

सूचकांक में अब सभी आवश्यक जानकारी शामिल है, और खोज सटीक रूप से की गई है:

 fts=# explain (costs off, analyze) select * from mail_messages where tsv @@ to_tsquery('hello <-> hackers'); 

  QUERY PLAN -------------------------------------------------------------------------------- Bitmap Heap Scan on mail_messages (actual time=2.798..3.015 rows=259 loops=1) Recheck Cond: (tsv @@ to_tsquery('hello <-> hackers'::text)) Heap Blocks: exact=250 -> Bitmap Index Scan on tsv_rum (actual time=2.768..2.768 rows=259 loops=1) Index Cond: (tsv @@ to_tsquery('hello <-> hackers'::text)) Planning time: 0.245 ms Execution time: 3.053 ms (7 rows) 

प्रासंगिकता के आधार पर छंटनी

आवश्यक क्रम में आसानी से दस्तावेजों को वापस करने के लिए, आरयूएम इंडेक्स ऑर्डर करने वाले ऑपरेटरों का समर्थन करता है, जिसकी हमने जीएसटी से संबंधित लेख में चर्चा की थी। RUM एक्सटेंशन ऐसे ऑपरेटर को परिभाषित करता है, <=> , जो दस्तावेज़ ("tsvector") और क्वेरी ("tsquery") के बीच कुछ दूरी लौटाता है। उदाहरण के लिए:

 fts=# select to_tsvector('Can a sheet slitter slit sheets?') <=&gtl to_tsquery('slit'); 

  ?column? ---------- 16.4493 (1 row) 

 fts=# select to_tsvector('Can a sheet slitter slit sheets?') <=> to_tsquery('sheet'); 

  ?column? ---------- 13.1595 (1 row) 

दस्तावेज़ पहली क्वेरी से दूसरे के लिए अधिक प्रासंगिक प्रतीत होता है: जितना अधिक बार यह शब्द होता है, उतना ही कम "मूल्यवान" होता है।

आइए फिर से GIN और RUM की तुलना अपेक्षाकृत बड़े डेटा साइज़ पर करने की कोशिश करें: हम "हैलो" और "हैकिंग" वाले दस सबसे अधिक प्रासंगिक दस्तावेज़ों का चयन करेंगे।

 fts=# explain (costs off, analyze) select * from mail_messages where tsv @@ to_tsquery('hello & hackers') order by ts_rank(tsv,to_tsquery('hello & hackers')) limit 10; 

  QUERY PLAN --------------------------------------------------------------------------------------------- Limit (actual time=27.076..27.078 rows=10 loops=1) -> Sort (actual time=27.075..27.076 rows=10 loops=1) Sort Key: (ts_rank(tsv, to_tsquery('hello & hackers'::text))) Sort Method: top-N heapsort Memory: 29kB -> Bitmap Heap Scan on mail_messages (actual ... rows=1776 loops=1) Recheck Cond: (tsv @@ to_tsquery('hello & hackers'::text)) Heap Blocks: exact=1503 -> Bitmap Index Scan on tsv_gin (actual ... rows=1776 loops=1) Index Cond: (tsv @@ to_tsquery('hello & hackers'::text)) Planning time: 0.276 ms Execution time: 27.121 ms (11 rows) 

GIN इंडेक्स 1776 मैच लौटाता है, जो तब दस सर्वश्रेष्ठ हिट का चयन करने के लिए एक अलग कदम के रूप में हल किया जाता है।

RUM इंडेक्स के साथ, क्वेरी को एक साधारण इंडेक्स स्कैन का उपयोग करके किया जाता है: किसी भी अतिरिक्त दस्तावेज़ के माध्यम से नहीं देखा जाता है, और अलग से छंटाई की आवश्यकता नहीं होती है:

 fts=# explain (costs off, analyze) select * from mail_messages where tsv @@ to_tsquery('hello & hackers') order by tsv <=> to_tsquery('hello & hackers') limit 10; 

  QUERY PLAN -------------------------------------------------------------------------------------------- Limit (actual time=5.083..5.171 rows=10 loops=1) -> Index Scan using tsv_rum on mail_messages (actual ... rows=10 loops=1) Index Cond: (tsv @@ to_tsquery('hello & hackers'::text)) Order By: (tsv <=> to_tsquery('hello & hackers'::text)) Planning time: 0.244 ms Execution time: 5.207 ms (6 rows) 

अतिरिक्त जानकारी

आरयूएम इंडेक्स, साथ ही जीआईएन, कई क्षेत्रों पर बनाया जा सकता है। लेकिन जब GIN दूसरे कॉलम से स्वतंत्र रूप से प्रत्येक कॉलम से लेक्सम को स्टोर करता है, RUM हमें एक अतिरिक्त के साथ मुख्य क्षेत्र ("tsvector") को "संबद्ध" करने में सक्षम बनाता है। ऐसा करने के लिए, हमें एक विशेष ऑपरेटर वर्ग "rum_tsvector_addon_ops" का उपयोग करने की आवश्यकता है:

 fts=# create index on mail_messages using rum(tsv RUM_TSVECTOR_ADDON_OPS, sent) WITH (ATTACH='sent', TO='tsv'); 

अतिरिक्त क्षेत्र पर छंटे परिणामों को वापस करने के लिए हम इस सूचकांक का उपयोग कर सकते हैं:

 fts=# select id, sent, sent <=> '2017-01-01 15:00:00' from mail_messages where tsv @@ to_tsquery('hello') order by sent <=> '2017-01-01 15:00:00' limit 10; 

  id | sent | ?column? ---------+---------------------+---------- 2298548 | 2017-01-01 15:03:22 | 202 2298547 | 2017-01-01 14:53:13 | 407 2298545 | 2017-01-01 13:28:12 | 5508 2298554 | 2017-01-01 18:30:45 | 12645 2298530 | 2016-12-31 20:28:48 | 66672 2298587 | 2017-01-02 12:39:26 | 77966 2298588 | 2017-01-02 12:43:22 | 78202 2298597 | 2017-01-02 13:48:02 | 82082 2298606 | 2017-01-02 15:50:50 | 89450 2298628 | 2017-01-02 18:55:49 | 100549 (10 rows) 

यहां हम उन पंक्तियों के मिलान के लिए खोज करते हैं जो निर्दिष्ट तिथि के करीब हैं, पहले या बाद में कोई फर्क नहीं पड़ता। निर्दिष्ट तारीख से पहले (या निम्नलिखित) सख्ती से परिणाम प्राप्त करने के लिए, हमें <=| का उपयोग करने की आवश्यकता है (या |=> ) ऑपरेटर।

जैसा कि हम उम्मीद करते हैं, क्वेरी केवल एक साधारण इंडेक्स स्कैन द्वारा की जाती है:

 ts=# explain (costs off) select id, sent, sent <=> '2017-01-01 15:00:00' from mail_messages where tsv @@ to_tsquery('hello') order by sent <=> '2017-01-01 15:00:00' limit 10; 

  QUERY PLAN --------------------------------------------------------------------------------- Limit -> Index Scan using mail_messages_tsv_sent_idx on mail_messages Index Cond: (tsv @@ to_tsquery('hello'::text)) Order By: (sent <=> '2017-01-01 15:00:00'::timestamp without time zone) (4 rows) 

यदि हमने फ़ील्ड एसोसिएशन पर अतिरिक्त जानकारी के बिना इंडेक्स बनाया है, तो एक समान क्वेरी के लिए, हमें इंडेक्स स्कैन के सभी परिणामों को सॉर्ट करना होगा।

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

अन्य ऑपरेटर कक्षाएं

तस्वीर को पूरा करने के लिए, हमें उपलब्ध अन्य ऑपरेटर कक्षाओं का उल्लेख करना चाहिए।

चलो "rum_tsvector_hash_ops" और "rum_tsvector_hash_addon_ops" से शुरू करते हैं । वे पहले से ही चर्चा किए गए "रुम_सेटरवॉटर_ओप्स" और "रुमव्सट्रक्टर_आडेन_ओप्स" के समान हैं, लेकिन इंडेक्स लेक्सेम के बजाय लेक्सम के हैश कोड को स्टोर करता है। यह सूचकांक आकार को कम कर सकता है, लेकिन निश्चित रूप से, खोज कम सटीक हो जाती है और पुन: जांच की आवश्यकता होती है। इसके अलावा, सूचकांक अब आंशिक मैच की खोज का समर्थन नहीं करता है।

यह दिलचस्प है "rum_tsquery_ops" ऑपरेटर वर्ग को देखने के लिए। यह हमें "उलटा" समस्या को हल करने में सक्षम बनाता है: दस्तावेज़ से मेल खाने वाले प्रश्नों को ढूंढें। इसकी जरूरत क्यों पड़ सकती है? उदाहरण के लिए, अपने फ़िल्टर के अनुसार या नए दस्तावेज़ों को स्वचालित रूप से वर्गीकृत करने के लिए एक उपयोगकर्ता को नए माल की सदस्यता के लिए। इस सरल उदाहरण को देखें:

 fts=# create table categories(query tsquery, category text); fts=# insert into categories values (to_tsquery('vacuum | autovacuum | freeze'), 'vacuum'), (to_tsquery('xmin | xmax | snapshot | isolation'), 'mvcc'), (to_tsquery('wal | (write & ahead & log) | durability'), 'wal'); fts=# create index on categories using rum(query); fts=# select array_agg(category) from categories where to_tsvector( 'Hello hackers, the attached patch greatly improves performance of tuple freezing and also reduces size of generated write-ahead logs.' ) @@ query; 

  array_agg -------------- {vacuum,wal} (1 row) 

शेष संचालक वर्ग "rum_anyarray_ops" और "rum_anyarray_addon_ops" को "tsvector" के बजाय सरणियों में हेरफेर करने के लिए डिज़ाइन किया गया है। यह पिछली बार GIN के लिए पहले से ही चर्चा में था और इसे दोहराने की आवश्यकता नहीं है।

सूचकांक के आकार और राइट-फॉरवर्ड लॉग (वाल)

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

  rum | gin | gist | btree --------+--------+--------+-------- 457 MB | 179 MB | 125 MB | 546 MB 

जैसा कि हम देख सकते हैं, आकार में काफी वृद्धि हुई, जो कि तेजी से खोज की लागत है।

यह एक और अधिक स्पष्ट बिंदु पर ध्यान देने योग्य है: आरयूएम एक विस्तार है, अर्थात, इसे सिस्टम कोर में किसी भी संशोधन के बिना स्थापित किया जा सकता है। यह सिकंदर कोरोटकोव द्वारा एक पैच के लिए धन्यवाद 9.6 संस्करण में सक्षम किया गया था। इस समस्या को हल करने के लिए एक समस्या यह थी कि लॉग रिकॉर्ड्स की पीढ़ी। संचालन के लॉगिंग के लिए एक तकनीक बिल्कुल विश्वसनीय होनी चाहिए, इसलिए, इस रसोई में विस्तार नहीं होने दिया जा सकता है। अपने स्वयं के प्रकार के लॉग रिकॉर्ड बनाने के लिए एक्सटेंशन की अनुमति देने के बजाय, निम्न स्थान पर है: एक्सटेंशन का कोड पृष्ठ को संशोधित करने के लिए अपने इरादे को बताता है, इसमें कोई भी बदलाव करता है, और पूरा होने का संकेत देता है, और यह सिस्टम कोर है, जो पेज के पुराने और नए संस्करणों की तुलना करता है और आवश्यक लॉग रिकॉर्ड बनाता है।

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

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

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

 fts=# select pg_current_wal_location() as start_lsn \gset 

 fts=# insert into mail_messages(parent_id, sent, subject, author, body_plain, tsv) select parent_id, sent, subject, author, body_plain, tsv from mail_messages where id % 100 = 0; 

 INSERT 0 3576 

 fts=# delete from mail_messages where id % 100 = 99; 

 DELETE 3590 

 fts=# vacuum mail_messages; 

 fts=# insert into mail_messages(parent_id, sent, subject, author, body_plain, tsv) select parent_id, sent, subject, author, body_plain, tsv from mail_messages where id % 100 = 1; 

 INSERT 0 3605 

 fts=# delete from mail_messages where id % 100 = 98; 

 DELETE 3637 

 fts=# vacuum mail_messages; 

 fts=# insert into mail_messages(parent_id, sent, subject, author, body_plain, tsv) select parent_id, sent, subject, author, body_plain, tsv from mail_messages where id % 100 = 2; 

 INSERT 0 3625 

 fts=# delete from mail_messages where id % 100 = 97; 

 DELETE 3668 

 fts=# vacuum mail_messages; 

 fts=# select pg_current_wal_location() as end_lsn \gset fts=# select pg_size_pretty(:'end_lsn'::pg_lsn - :'start_lsn'::pg_lsn); 

  pg_size_pretty ---------------- 3114 MB (1 row) 

तो, हमें लगभग 3 जीबी मिलता है। लेकिन अगर हम GIN इंडेक्स के साथ एक ही प्रयोग दोहराते हैं, तो यह लगभग 700 एमबी का होगा।

इसलिए, एक अलग एल्गोरिथ्म होना वांछनीय है, जो कि न्यूनतम संख्या डालें और ऑपरेशन को हटा दें जो पृष्ठ के एक राज्य को दूसरे में बदल सकते हैं। "डिफ" उपयोगिता एक समान तरीके से काम करती है। ओलेग इवानोव ने पहले से ही इस तरह के एल्गोरिदम को लागू किया है, और उनके पैच पर चर्चा की जा रही है। उपरोक्त उदाहरण में, यह पैच हमें एक छोटे से मंदी की कीमत पर, लॉग रिकॉर्ड के आकार को १.५ एमबी तक कम करने में सक्षम बनाता है।

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

गुण

हमेशा की तरह, RUM पहुंच विधि के गुणों को देखें, GIN से अंतरों पर ध्यान देते हुए (प्रश्न पहले ही प्रदान किए जा चुके हैं )।

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

  amname | name | pg_indexam_has_property --------+---------------+------------------------- rum | can_order | f rum | can_unique | f rum | can_multi_col | t rum | can_exclude | t -- f for gin 

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

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

ध्यान दें कि, GIN के विपरीत, RUM सूचकांक स्कैन का समर्थन करता है - अन्यथा, "सीमा" खंड के साथ प्रश्नों में परिणाम की आवश्यक संख्या को वापस करना संभव नहीं होगा। तदनुसार "gin_fuzzy_search_limit" पैरामीटर के समकक्ष की आवश्यकता नहीं है। और परिणामस्वरूप, इंडेक्स का उपयोग बहिष्करण बाधाओं का समर्थन करने के लिए किया जा सकता है।

निम्नलिखित स्तंभ-परत गुण हैं:

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

यहां अंतर यह है कि RUM ऑर्डर करने वाले ऑपरेटरों का समर्थन करता है। हालांकि, यह सभी ऑपरेटर वर्गों के लिए सही नहीं है: उदाहरण के लिए, यह "tsquery_ops" के लिए गलत है।

पर पढ़ें ।