ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಜಗತ್ತಿನಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ಸಂಗ್ರಹಣೆಯ ಸಮರ್ಥ ಸಂಚರಣೆಗಾಗಿ ಸೂಚ್ಯಂಕಗಳು ಅತ್ಯಗತ್ಯವಾಗಿರುತ್ತದೆ ("ರಾಶಿ" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ). Postgres ಅದಕ್ಕೆ ಕ್ಲಸ್ಟರಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು MVCC ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಂದೇ ಟುಪಲ್‌ನ ಹಲವು ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವಂತೆ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸಲು ಸಮರ್ಥ ಸೂಚಿಕೆಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದು ಬಹಳ ಮುಖ್ಯ.
ಸೂಚ್ಯಂಕಗಳ ಬಳಕೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಮತ್ತು ಸುಧಾರಿಸಲು ಕೆಲವು ಸಲಹೆಗಳು ಇಲ್ಲಿವೆ.
ಗಮನಿಸಿ: ಕೆಳಗೆ ತೋರಿಸಿರುವ ಪ್ರಶ್ನೆಗಳು ಮಾರ್ಪಡಿಸದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ .
ಹೊದಿಕೆ ಸೂಚ್ಯಂಕಗಳನ್ನು ಬಳಸುವುದು
ನಿಷ್ಕ್ರಿಯ ಬಳಕೆದಾರರಿಗಾಗಿ ಇಮೇಲ್ ವಿಳಾಸಗಳನ್ನು ಹೊರತೆಗೆಯಲು ವಿನಂತಿಯನ್ನು ನೋಡೋಣ. ಟೇಬಲ್ 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)ಸೂಚ್ಯಂಕವನ್ನು ಸಹ ಪರಿಗಣಿಸಲಾಗಿಲ್ಲ. ಬಿ-ಟ್ರೀ ಸೂಚ್ಯಂಕವು ಸೂಚ್ಯಂಕ ಮೌಲ್ಯಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಅಂಶಗಳ ಅಸ್ತಿತ್ವದ ಬಗ್ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ.
ನಮಗೆ ಜಿಐಎನ್ ಸೂಚ್ಯಂಕ ಅಗತ್ಯವಿದೆ.
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)ಜಿಐಎನ್ ಸೂಚ್ಯಂಕವು ಸೂಚ್ಯಂಕದ ಸಂಯೋಜಿತ ಮೌಲ್ಯಗಳ ವಿರುದ್ಧ ಏಕ ಮೌಲ್ಯಗಳನ್ನು ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಪ್ರಶ್ನೆ ಯೋಜನೆ ವೆಚ್ಚವು ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಡಿಮೆಯಾಗಿದೆ.
ನಕಲಿ ಸೂಚ್ಯಂಕಗಳನ್ನು ತೊಡೆದುಹಾಕುವುದು
ಸೂಚ್ಯಂಕಗಳು ಕಾಲಾನಂತರದಲ್ಲಿ ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಹೊಸ ಸೂಚ್ಯಂಕವು ಹಿಂದಿನ ಪದಗಳಿಗಿಂತ ಅದೇ ವ್ಯಾಖ್ಯಾನವನ್ನು ಹೊಂದಿರಬಹುದು. ಸೂಚ್ಯಂಕಗಳ ಮಾನವ-ಓದಬಲ್ಲ 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_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