PostgreSQL ਵਿੱਚ ਸੂਚਕਾਂਕ ਦੀਆਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਪੋਸਟਗ੍ਰੇਸ ਸੰਸਾਰ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਸਟੋਰੇਜ (ਜਿਸਨੂੰ "ਹੀਪ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਦੀ ਕੁਸ਼ਲ ਨੈਵੀਗੇਸ਼ਨ ਲਈ ਸੂਚਕਾਂਕ ਜ਼ਰੂਰੀ ਹਨ। ਪੋਸਟਗ੍ਰੇਸ ਇਸਦੇ ਲਈ ਕਲੱਸਟਰਿੰਗ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਅਤੇ MVCC ਆਰਕੀਟੈਕਚਰ ਤੁਹਾਨੂੰ ਇੱਕੋ ਟੂਪਲ ਦੇ ਕਈ ਸੰਸਕਰਣਾਂ ਨਾਲ ਖਤਮ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਇਸ ਲਈ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਕੁਸ਼ਲ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਅਤੇ ਬਣਾਈ ਰੱਖਣ ਦੇ ਯੋਗ ਹੋਣਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਅਤੇ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਇੱਥੇ ਕੁਝ ਸੁਝਾਅ ਹਨ।

ਨੋਟ: ਹੇਠਾਂ ਦਰਸਾਏ ਗਏ ਸਵਾਲ ਇੱਕ ਅਣਸੋਧਿਆ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ pagila ਨਮੂਨਾ ਡਾਟਾਬੇਸ.

ਕਵਰਿੰਗ ਇੰਡੈਕਸਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਆਉ ਨਾ-ਸਰਗਰਮ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਈਮੇਲ ਪਤਿਆਂ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਦੀ ਬੇਨਤੀ ਨੂੰ ਵੇਖੀਏ। ਟੇਬਲ customer ਇੱਕ ਕਾਲਮ ਹੈ active, ਅਤੇ ਪੁੱਛਗਿੱਛ ਸਧਾਰਨ ਹੈ:

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                        QUERY PLAN
-----------------------------------------------------------
 Seq Scan on customer  (cost=0.00..16.49 rows=15 width=32)
   Filter: (active = 0)
(2 rows)

ਪੁੱਛਗਿੱਛ ਪੂਰੀ ਟੇਬਲ ਸਕੈਨ ਕ੍ਰਮ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ customer. ਚਲੋ ਇੱਕ ਕਾਲਮ ਉੱਤੇ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਈਏ active:

pagila=# CREATE INDEX idx_cust1 ON customer(active);
CREATE INDEX
pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Index Scan using idx_cust1 on customer  (cost=0.28..12.29 rows=15 width=32)
   Index Cond: (active = 0)
(2 rows)

ਇਸਨੇ ਮਦਦ ਕੀਤੀ, ਬਾਅਦ ਵਿੱਚ ਸਕੈਨ " ਵਿੱਚ ਬਦਲ ਗਿਆindex scan". ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪੋਸਟਗ੍ਰੇਸ ਸੂਚਕਾਂਕ ਨੂੰ ਸਕੈਨ ਕਰੇਗਾ "idx_cust1", ਅਤੇ ਫਿਰ ਦੂਜੇ ਕਾਲਮਾਂ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਟੇਬਲ ਹੀਪ ਦੀ ਖੋਜ ਕਰਨਾ ਜਾਰੀ ਰੱਖੋ (ਇਸ ਕੇਸ ਵਿੱਚ, ਕਾਲਮ email) ਜਿਸ ਦੀ ਪੁੱਛਗਿੱਛ ਦੀ ਲੋੜ ਹੈ।

ਕਵਰਿੰਗ ਇੰਡੈਕਸ PostgreSQL 11 ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਨ। ਉਹ ਤੁਹਾਨੂੰ ਸੂਚਕਾਂਕ ਵਿੱਚ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਧੂ ਕਾਲਮਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ - ਉਹਨਾਂ ਦੇ ਮੁੱਲ ਸੂਚਕਾਂਕ ਡੇਟਾ ਸਟੋਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ.

ਜੇਕਰ ਅਸੀਂ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਫਾਇਦਾ ਉਠਾਉਂਦੇ ਹਾਂ ਅਤੇ ਸੂਚਕਾਂਕ ਦੇ ਅੰਦਰ ਈਮੇਲ ਮੁੱਲ ਜੋੜਦੇ ਹਾਂ, ਤਾਂ ਪੋਸਟਗ੍ਰੇਸ ਨੂੰ ਮੁੱਲ ਲਈ ਟੇਬਲ ਹੀਪ ਦੀ ਖੋਜ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ। email. ਆਓ ਦੇਖੀਏ ਕਿ ਕੀ ਇਹ ਕੰਮ ਕਰੇਗਾ:

pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);
CREATE INDEX
pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                                    QUERY PLAN
----------------------------------------------------------------------------------
 Index Only Scan using idx_cust2 on customer  (cost=0.28..12.29 rows=15 width=32)
   Index Cond: (active = 0)
(2 rows)

«Index Only Scan' ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪੁੱਛਗਿੱਛ ਨੂੰ ਹੁਣ ਸਿਰਫ਼ ਇੰਡੈਕਸ ਦੀ ਲੋੜ ਹੈ, ਜੋ ਕਿ ਟੇਬਲ ਹੀਪ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਸਾਰੀਆਂ ਡਿਸਕ I/O ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਕਵਰਿੰਗ ਸੂਚਕਾਂਕ ਵਰਤਮਾਨ ਵਿੱਚ ਸਿਰਫ ਬੀ-ਰੁੱਖਾਂ ਲਈ ਉਪਲਬਧ ਹਨ। ਹਾਲਾਂਕਿ, ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਰੱਖ-ਰਖਾਅ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਧੇਰੇ ਹੋਵੇਗੀ.

ਅੰਸ਼ਕ ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਅੰਸ਼ਕ ਸੂਚਕਾਂਕ ਸਾਰਣੀ ਵਿੱਚ ਕਤਾਰਾਂ ਦੇ ਸਿਰਫ਼ ਇੱਕ ਉਪ ਸਮੂਹ ਨੂੰ ਸੂਚਕਾਂਕ ਕਰਦੇ ਹਨ। ਇਹ ਸੂਚਕਾਂਕ ਦੇ ਆਕਾਰ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਸਕੈਨ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ ਕੈਲੀਫੋਰਨੀਆ ਵਿੱਚ ਆਪਣੇ ਗਾਹਕਾਂ ਦੇ ਈਮੇਲ ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਬੇਨਤੀ ਇਸ ਤਰ੍ਹਾਂ ਹੋਵੇਗੀ:

SELECT c.email FROM customer c
JOIN address a ON c.address_id = a.address_id
WHERE a.district = 'California';
which has a query plan that involves scanning both the tables that are joined:
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                              QUERY PLAN
----------------------------------------------------------------------
 Hash Join  (cost=15.65..32.22 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=15.54..15.54 rows=9 width=4)
         ->  Seq Scan on address a  (cost=0.00..15.54 rows=9 width=4)
               Filter: (district = 'California'::text)
(6 rows)

ਆਮ ਸੂਚਕਾਂਕ ਸਾਨੂੰ ਕੀ ਦੇਣਗੇ:

pagila=# CREATE INDEX idx_address1 ON address(district);
CREATE INDEX
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                                      QUERY PLAN
---------------------------------------------------------------------------------------
 Hash Join  (cost=12.98..29.55 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=12.87..12.87 rows=9 width=4)
         ->  Bitmap Heap Scan on address a  (cost=4.34..12.87 rows=9 width=4)
               Recheck Cond: (district = 'California'::text)
               ->  Bitmap Index Scan on idx_address1  (cost=0.00..4.34 rows=9 width=0)
                     Index Cond: (district = 'California'::text)
(8 rows)

ਸਕੈਨ ਕਰੋ address ਇੰਡੈਕਸ ਸਕੈਨ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ idx_address1, ਅਤੇ ਫਿਰ ਢੇਰ ਨੂੰ ਸਕੈਨ ਕੀਤਾ ਗਿਆ ਸੀ address.

ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਅਕਸਰ ਪੁੱਛਗਿੱਛ ਹੈ ਅਤੇ ਇਸਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਸੀਂ ਇੱਕ ਅੰਸ਼ਕ ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਜੋ ਸਿਰਫ਼ ਉਹਨਾਂ ਕਤਾਰਾਂ ਨੂੰ ਪਤਿਆਂ ਦੇ ਨਾਲ ਸੂਚਕਾਂਕ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਜ਼ਿਲ੍ਹਾ ‘California’:

pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';
CREATE INDEX
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Hash Join  (cost=12.38..28.96 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=12.27..12.27 rows=9 width=4)
         ->  Index Only Scan using idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)
(5 rows)

ਹੁਣ ਸਵਾਲ ਹੀ ਪੜ੍ਹਦਾ ਹੈ idx_address2 ਅਤੇ ਮੇਜ਼ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ address.

ਬਹੁ-ਮੁੱਲ ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਇੰਡੈਕਸ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਕੁਝ ਕਾਲਮਾਂ ਵਿੱਚ ਇੱਕ ਸਕੇਲਰ ਡਾਟਾ ਕਿਸਮ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਕਾਲਮ ਦੀਆਂ ਕਿਸਮਾਂ ਜਿਵੇਂ jsonb, arrays и tsvector ਸੰਯੁਕਤ ਜਾਂ ਮਲਟੀਪਲ ਮੁੱਲ ਸ਼ਾਮਲ ਹਨ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਕਾਲਮਾਂ ਨੂੰ ਇੰਡੈਕਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਕਾਲਮਾਂ ਦੇ ਸਾਰੇ ਵਿਅਕਤੀਗਤ ਮੁੱਲਾਂ ਦੀ ਖੋਜ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।

ਆਉ ਉਹਨਾਂ ਸਾਰੀਆਂ ਫਿਲਮਾਂ ਦੇ ਸਿਰਲੇਖਾਂ ਨੂੰ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਜਿਸ ਵਿੱਚ ਅਸਫਲ ਟੇਕਸ ਤੋਂ ਕੱਟ ਹਨ। ਟੇਬਲ film ਇੱਕ ਟੈਕਸਟ ਕਾਲਮ ਹੈ ਜਿਸਨੂੰ ਕਹਿੰਦੇ ਹਨ special_features. ਜੇਕਰ ਫਿਲਮ ਵਿੱਚ ਇਹ "ਵਿਸ਼ੇਸ਼ ਸੰਪਤੀ" ਹੈ, ਤਾਂ ਕਾਲਮ ਵਿੱਚ ਇੱਕ ਟੈਕਸਟ ਐਰੇ ਦੇ ਰੂਪ ਵਿੱਚ ਤੱਤ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ Behind The Scenes. ਅਜਿਹੀਆਂ ਸਾਰੀਆਂ ਫਿਲਮਾਂ ਦੀ ਖੋਜ ਕਰਨ ਲਈ, ਸਾਨੂੰ "ਬਿਹਾਈਂਡ ਦਿ ਸੀਨਜ਼" ਨਾਲ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਵੀ ਐਰੇ ਮੁੱਲ special_features:

SELECT title FROM film WHERE special_features @> '{"Behind The Scenes"}';

ਨੇਸਟਿੰਗ ਆਪਰੇਟਰ @> ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸੱਜਾ ਪਾਸਾ ਖੱਬੇ ਪਾਸੇ ਦਾ ਸਬਸੈੱਟ ਹੈ।

ਯੋਜਨਾ ਦੀ ਬੇਨਤੀ ਕਰੋ:

pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)
   Filter: (special_features @> '{"Behind The Scenes"}'::text[])
(2 rows)

ਜੋ ਕਿ 67 ਦੀ ਲਾਗਤ ਨਾਲ ਪੂਰੇ ਹੀਪ ਸਕੈਨ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ।

ਆਓ ਦੇਖੀਏ ਕਿ ਕੀ ਇੱਕ ਨਿਯਮਤ ਬੀ-ਟ੍ਰੀ ਇੰਡੈਕਸ ਸਾਡੀ ਮਦਦ ਕਰਦਾ ਹੈ:

pagila=# CREATE INDEX idx_film1 ON film(special_features);
CREATE INDEX
pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)
   Filter: (special_features @> '{"Behind The Scenes"}'::text[])
(2 rows)

ਸੂਚਕਾਂਕ 'ਤੇ ਵੀ ਵਿਚਾਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ। ਬੀ-ਟ੍ਰੀ ਇੰਡੈਕਸ ਸੂਚਕਾਂਕ ਮੁੱਲਾਂ ਵਿੱਚ ਵਿਅਕਤੀਗਤ ਤੱਤਾਂ ਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਜਾਣੂ ਨਹੀਂ ਹੈ।

ਸਾਨੂੰ ਇੱਕ GIN ਸੂਚਕਾਂਕ ਦੀ ਲੋੜ ਹੈ।

pagila=# CREATE INDEX idx_film2 ON film USING GIN(special_features);
CREATE INDEX
pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                                QUERY PLAN
---------------------------------------------------------------------------
 Bitmap Heap Scan on film  (cost=8.04..23.58 rows=5 width=15)
   Recheck Cond: (special_features @> '{"Behind The Scenes"}'::text[])
   ->  Bitmap Index Scan on idx_film2  (cost=0.00..8.04 rows=5 width=0)
         Index Cond: (special_features @> '{"Behind The Scenes"}'::text[])
(4 rows)

GIN ਸੂਚਕਾਂਕ ਇੰਡੈਕਸ ਕੀਤੇ ਮਿਸ਼ਰਿਤ ਮੁੱਲਾਂ ਦੇ ਵਿਰੁੱਧ ਸਿੰਗਲ ਮੁੱਲਾਂ ਦੀ ਮੈਪਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਪੁੱਛਗਿੱਛ ਯੋਜਨਾ ਦੀ ਲਾਗਤ ਅੱਧੇ ਤੋਂ ਵੱਧ ਹੈ।

ਡੁਪਲੀਕੇਟ ਸੂਚਕਾਂਕ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ

ਸੂਚਕਾਂਕ ਸਮੇਂ ਦੇ ਨਾਲ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰ ਇੱਕ ਨਵੇਂ ਸੂਚਕਾਂਕ ਵਿੱਚ ਪਿਛਲੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਪਰਿਭਾਸ਼ਾ ਹੋ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਸੂਚਕਾਂਕ ਦੀਆਂ ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ SQL ਪਰਿਭਾਸ਼ਾਵਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੈਟਾਲਾਗ ਦ੍ਰਿਸ਼ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। pg_indexes. ਤੁਸੀਂ ਇੱਕੋ ਜਿਹੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਲੱਭ ਸਕਦੇ ਹੋ:

 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn
    FROM pg_indexes
GROUP BY defn
  HAVING count(*) > 1;
And here’s the result when run on the stock pagila database:
pagila=#   SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn
pagila-#     FROM pg_indexes
pagila-# GROUP BY defn
pagila-#   HAVING count(*) > 1;
                                indexes                                 |                                defn
------------------------------------------------------------------------+------------------------------------------------------------------
 {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | CREATE INDEX  ON public.payment_p2017_01 USING btree (customer_id
 {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | CREATE INDEX  ON public.payment_p2017_02 USING btree (customer_id
 {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | CREATE INDEX  ON public.payment_p2017_03 USING btree (customer_id
 {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_04 USING btree (customer_id
 {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | CREATE INDEX  ON public.payment_p2017_05 USING btree (customer_id
 {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_06 USING btree (customer_id
(6 rows)

ਸੁਪਰਸੈੱਟ ਸੂਚਕਾਂਕ

ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਸੂਚਕਾਂਕ ਦੇ ਨਾਲ ਖਤਮ ਹੋਵੋ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਾਲਮਾਂ ਦੇ ਇੱਕ ਸੁਪਰਸੈੱਟ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜੋ ਦੂਜੇ ਸੂਚਕਾਂਕ ਨੂੰ ਸੂਚਕਾਂਕ ਕਰਦਾ ਹੈ। ਇਹ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਵੀ ਹੋ ਸਕਦਾ ਹੈ—ਸੁਪਰਸੈੱਟ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸਿਰਫ਼-ਸੂਚਕਾਂਕ ਸਕੈਨ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਕਿ ਚੰਗਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਥਾਂ ਲੈ ਸਕਦਾ ਹੈ, ਜਾਂ ਉਹ ਪੁੱਛਗਿੱਛ ਜੋ ਸੁਪਰਸੈੱਟ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਹੁਣ ਵਰਤਿਆ ਨਹੀਂ ਜਾਵੇਗਾ।

ਜੇ ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਸੂਚਕਾਂਕ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ pg_index ਮੇਜ਼ ਤੋਂ pg_catalog.

ਨਾ ਵਰਤੇ ਸੂਚਕਾਂਕ

ਜਿਵੇਂ ਕਿ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿਕਸਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਉਸੇ ਤਰ੍ਹਾਂ ਉਹਨਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ ਵੀ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾਂ ਸ਼ਾਮਲ ਕੀਤੇ ਸੂਚਕਾਂਕ ਹੁਣ ਕਿਸੇ ਵੀ ਪੁੱਛਗਿੱਛ ਦੁਆਰਾ ਨਹੀਂ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਹਰ ਵਾਰ ਜਦੋਂ ਇੱਕ ਸੂਚਕਾਂਕ ਨੂੰ ਸਕੈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਅੰਕੜਾ ਪ੍ਰਬੰਧਕ ਦੁਆਰਾ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਕੈਟਾਲਾਗ ਦ੍ਰਿਸ਼ ਵਿੱਚ pg_stat_user_indexes ਤੁਸੀਂ ਮੁੱਲ ਦੇਖ ਸਕਦੇ ਹੋ idx_scan, ਜੋ ਕਿ ਇੱਕ ਸੰਚਤ ਕਾਊਂਟਰ ਹੈ। ਸਮੇਂ ਦੀ ਇੱਕ ਮਿਆਦ (ਇੱਕ ਮਹੀਨਾ ਕਹੋ) ਵਿੱਚ ਇਸ ਮੁੱਲ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਦੇਵੇਗਾ ਕਿ ਕਿਹੜੇ ਸੂਚਕਾਂਕ ਵਰਤੇ ਨਹੀਂ ਜਾ ਰਹੇ ਹਨ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਛੱਡਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਸਕੀਮਾ ਵਿੱਚ ਸਾਰੇ ਸੂਚਕਾਂਕ ਦੀ ਮੌਜੂਦਾ ਸਕੈਨ ਗਿਣਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਥੇ ਇੱਕ ਪੁੱਛਗਿੱਛ ਹੈ ‘public’:

SELECT relname, indexrelname, idx_scan
FROM   pg_catalog.pg_stat_user_indexes
WHERE  schemaname = 'public';
with output like this:
pagila=# SELECT relname, indexrelname, idx_scan
pagila-# FROM   pg_catalog.pg_stat_user_indexes
pagila-# WHERE  schemaname = 'public'
pagila-# LIMIT  10;
    relname    |    indexrelname    | idx_scan
---------------+--------------------+----------
 customer      | customer_pkey      |    32093
 actor         | actor_pkey         |     5462
 address       | address_pkey       |      660
 category      | category_pkey      |     1000
 city          | city_pkey          |      609
 country       | country_pkey       |      604
 film_actor    | film_actor_pkey    |        0
 film_category | film_category_pkey |        0
 film          | film_pkey          |    11043
 inventory     | inventory_pkey     |    16048
(10 rows)

ਘੱਟ ਤਾਲੇ ਦੇ ਨਾਲ ਸੂਚਕਾਂਕ ਨੂੰ ਮੁੜ ਬਣਾਉਣਾ

ਸੂਚਕਾਂਕ ਨੂੰ ਅਕਸਰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਜਦੋਂ ਉਹ ਫੁੱਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਸਕੈਨ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ। ਸੂਚਕਾਂਕ ਵੀ ਖਰਾਬ ਹੋ ਸਕਦੇ ਹਨ। ਸੂਚਕਾਂਕ ਮਾਪਦੰਡਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਵੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਪੈਰਲਲ ਇੰਡੈਕਸ ਬਣਾਉਣ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ

PostgreSQL 11 ਵਿੱਚ, ਇੱਕ ਬੀ-ਟ੍ਰੀ ਇੰਡੈਕਸ ਬਣਾਉਣਾ ਸਮਕਾਲੀ ਹੈ। ਰਚਨਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ, ਕਈ ਸਮਾਨਾਂਤਰ ਕਾਮਿਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਸੰਰਚਨਾ ਵਿਕਲਪ ਸਹੀ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕੀਤੇ ਗਏ ਹਨ:

SET max_parallel_workers = 32;
SET max_parallel_maintenance_workers = 16;

ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲ ਬਹੁਤ ਛੋਟੇ ਹਨ। ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਇਹ ਸੰਖਿਆ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਦੀ ਗਿਣਤੀ ਦੇ ਨਾਲ ਵਧਣੀ ਚਾਹੀਦੀ ਹੈ. ਵਿੱਚ ਹੋਰ ਪੜ੍ਹੋ ਦਸਤਾਵੇਜ਼.

ਬੈਕਗ੍ਰਾਊਂਡ ਇੰਡੈਕਸ ਬਣਾਉਣਾ

ਤੁਸੀਂ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾ ਸਕਦੇ ਹੋ CONCURRENTLY ਕਮਾਂਡਾਂ CREATE INDEX:

pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);
CREATE INDEX

ਇਹ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਆਮ ਨਾਲੋਂ ਵੱਖਰੀ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਟੇਬਲ 'ਤੇ ਲਾਕ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸਲਈ ਲਿਖਣ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਬਲੌਕ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਦੂਜੇ ਪਾਸੇ, ਇਹ ਵਧੇਰੇ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਅਤੇ ਵਧੇਰੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ.

ਪੋਸਟਗ੍ਰੇਸ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਅਤੇ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਕੇਸਾਂ ਨਾਲ ਨਜਿੱਠਣ ਦੇ ਤਰੀਕਿਆਂ ਦੇ ਨਾਲ-ਨਾਲ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵਿਸਫੋਟ ਨਾਲ ਵਧਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਡੇਟਾਬੇਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਚਕਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਸੁਝਾਅ ਤੁਹਾਡੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਸਕੇਲ ਕਰਨ ਲਈ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨਗੇ।

ਸਰੋਤ: www.habr.com