PostgreSQL में, कई DDL कमांड को निष्पादित होने में बहुत लंबा समय लग सकता है। PostgreSQL में कमांड निष्पादन के दौरान DDL कमांड की प्रगति की रिपोर्ट करने की क्षमता है। PostgreSQL 9.6 के बाद से, एक समर्पित सिस्टम कैटलॉग (जिसे pg_stat_progress_vacuum कहा जाता है) का उपयोग करके मैन्युअल VACUUM और ऑटोवैक्यूम चलाने की प्रगति की निगरानी करना संभव हो गया है।
PostgreSQL 12 ने कुछ और कमांड जैसे CLUSTER, VACUUM FULL, CREATE INDEX, और REINDEX की प्रगति की निगरानी के लिए समर्थन जोड़ा है।
वर्तमान में, प्रगति रिपोर्टिंग सुविधा केवल निम्न कमांड के लिए उपलब्ध है।
- VACUUM कमांड
- क्लस्टर कमांड
- VACUUM पूर्ण आदेश
- इंडेक्स कमांड बनाएं
- REINDEX कमांड
PostgreSQL में प्रगति रिपोर्टिंग विशेषता क्यों महत्वपूर्ण है?
कुछ लंबे समय तक चलने वाले ऑपरेशन करते समय ऑपरेटरों के लिए यह सुविधा बहुत महत्वपूर्ण है, क्योंकि किसी ऑपरेशन के समाप्त होने की प्रतीक्षा करना संभव नहीं है।
कुछ अंतर्दृष्टि प्राप्त करने के लिए यह एक बहुत ही उपयोगी विशेषता है जैसे:
- वहां कुल कितना काम है
- कितना काम पहले ही किया जा चुका है
प्रदर्शन कार्यभार विश्लेषण करते समय प्रगति रिपोर्टिंग सुविधा भी उपयोगी होती है, यह लोड पैटर्न के आधार पर एक बार सिस्टम-स्तरीय मापदंडों या संबंध स्तर को ट्यून करने के लिए VACUUM जॉब प्रोसेसिंग के मूल्यांकन में भी उपयोगी साबित हो रही है।
समर्थित कमांड और सिस्टम कैटलॉग
DDL Command | सिस्टम कैटलॉग | समर्थित PostgreSQL संस्करण |
VACUUM | pg_stat_progress_vacuum | 9.6 |
वैक्यूम पूर्ण | pg_stat_progress_cluster | 12 |
CLUSTER | pg_stat_progress_cluster | 12 |
इंडेक्स बनाएं | pg_stat_progress_create_index | 12 |
REINDEX | pg_stat_progress_create_index | 12 |
वैक्यूम कमांड की प्रगति की निगरानी कैसे करें
जब भी VACUUM कमांड चल रहा हो, pg_stat_progress_vacuum दृश्य में प्रत्येक बैकएंड (ऑटोवैक्यूम वर्कर प्रक्रियाओं सहित) के लिए एक पंक्ति होगी जो वर्तमान में वैक्यूम कर रही है। VACUUM और VACCUM FULL कमांड चलाने की प्रगति की जाँच करने का दृष्टिकोण अलग है क्योंकि दोनों कमांड के ऑपरेशन चरण अलग-अलग हैं।
वैक्यूम कमांड के ऑपरेशन चरण
- आरंभ कर रहा है
- हीप स्कैन करना
- निर्वात अनुक्रमणिका
- वैक्यूमिंग हीप
- अनुक्रमणिका साफ़ करना
- ढेर को छोटा करना
- अंतिम सफाई करना
यह दृश्य PostgreSQL 12 में उपलब्ध है जो निम्नलिखित जानकारी देता है:
postgres=# \d pg_stat_progress_vacuum ;
View "pg_catalog.pg_stat_progress_vacuum"
Column | Type | Collation | Nullable | Default
--------------------+---------+-----------+----------+---------
pid | integer | | |
datid | oid | | |
datname | name | | |
relid | oid | | |
phase | text | | |
heap_blks_total | bigint | | |
heap_blks_scanned | bigint | | |
heap_blks_vacuumed | bigint | | |
index_vacuum_count | bigint | | |
max_dead_tuples | bigint | | |
num_dead_tuples | bigint | | |
उदाहरण:
postgres=# create table test ( a int, b varchar(40), c timestamp );
CREATE TABLE
postgres=# insert into test ( a, b, c ) select aa, bb, cc from generate_series(1,10000000) aa, md5(aa::varchar) bb, now() cc;
INSERT 0 10000000
postgres=# DELETE FROM test WHERE mod(a,6) = 0;
DELETE 1666666
सत्र 1:
postgres=# vacuum verbose test;
[. . . waits for completion . . .]
सत्र 2:
postgres=# select * from pg_stat_progress_vacuum;
-[ RECORD 1 ]------+--------------
pid | 22800
datid | 14187
datname | postgres
relid | 16388
phase | scanning heap
heap_blks_total | 93458
heap_blks_scanned | 80068
heap_blks_vacuumed | 80067
index_vacuum_count | 0
max_dead_tuples | 291
num_dead_tuples | 18
CLUSTER और VACUUM FULL के लिए प्रगति रिपोर्टिंग
CLUSTER और VACUUM FULL कमांड संबंध पुनर्लेखन के लिए समान कोड पथ का उपयोग करते हैं, इसलिए आप pg_stat_progress_cluster दृश्य का उपयोग करके दोनों कमांड की प्रगति की जांच कर सकते हैं।
यह दृश्य PostgreSQL 12 में उपलब्ध है और यह निम्न जानकारी दिखाता है:
postgres=# \d pg_stat_progress_cluster
View "pg_catalog.pg_stat_progress_cluster"
Column | Type | Collation | Nullable | Default
---------------------+---------+-----------+----------+---------
pid | integer | | |
datid | oid | | |
datname | name | | |
relid | oid | | |
command | text | | |
phase | text | | |
cluster_index_relid | bigint | | |
heap_tuples_scanned | bigint | | |
heap_tuples_written | bigint | | |
heap_blks_total | bigint | | |
heap_blks_scanned | bigint | | |
index_rebuild_count | bigint | | |
क्लस्टर कमांड के ऑपरेशन चरण
- आरंभ कर रहा है
- Seq स्कैनिंग हीप
- इंडेक्स स्कैनिंग हीप
- टुपल्स को सॉर्ट करना
- नया ढेर लिखना
- संबंध फाइलों की अदला-बदली
- पुनर्निर्माण अनुक्रमणिका
- अंतिम सफाई करना
उदाहरण:
postgres=# create table test as select a,md5(a::text) as txt, now() as date from generate_series(1,3000000) a;
SELECT 3000000
postgres=# create index idx1 on test(a);
CREATE INDEX
postgres=# create index idx2 on test(txt);
CREATE INDEX
postgres=# create index idx3 on test(date);
CREATE INDEX
Now execute the CLUSTER table command and see the progress in pg_stat_progress_cluster.
सत्र 1:
postgres=# cluster verbose test using idx1;
[. . . waits for completion . . .]
सत्र 2:
postgres=# select * from pg_stat_progress_cluster;
pid | datid | datname | relid | command | phase | cluster_index_relid | heap_tuples_scanned | heap_tuples_written | heap_blks_total | heap_blks_scanned | index_rebuild_count
------+-------+----------+-------+---------+------------------+---------------------+---------------------+---------------------+-----------------+-------------------+---------------------
1273 | 13586 | postgres | 15672 | CLUSTER | rebuilding index | 15680 | 3000000 | 3000000 | 0 | 0 | 2
(1 row)
इंडेक्स और रीइंडेक्स बनाने के लिए प्रगति रिपोर्टिंग
जब भी क्रिएट इंडेक्स या रीइंडेक्स कमांड चल रहा हो, तो pg_stat_progress_create_index व्यू में प्रत्येक बैकएंड के लिए एक पंक्ति होगी जो वर्तमान में इंडेक्स बना रहा है। प्रगति रिपोर्टिंग सुविधा क्रिएट इंडेक्स और रीइंडेक्स के समवर्ती स्वादों को भी ट्रैक करने की अनुमति देती है। CREATE INDEX और REINDEX कमांड के आंतरिक निष्पादन चरण समान हैं, इसलिए आप एक ही दृश्य का उपयोग करके दोनों कमांड की प्रगति की जांच कर सकते हैं।
postgres=# \d pg_stat_progress_create_index
View "pg_catalog.pg_stat_progress_create_index"
Column | Type | Collation | Nullable | Default
--------------------+---------+-----------+----------+---------
pid | integer | | |
datid | oid | | |
datname | name | | |
relid | oid | | |
phase | text | | |
lockers_total | bigint | | |
lockers_done | bigint | | |
current_locker_pid | bigint | | |
blocks_total | bigint | | |
blocks_done | bigint | | |
tuples_total | bigint | | |
tuples_done | bigint | | |
partitions_total | bigint | | |
partitions_done | bigint | | |
क्रिएट इंडेक्स / रीइंडेक्स के संचालन चरण
- आरंभ कर रहा है
- निर्माण से पहले लेखकों की प्रतीक्षा कर रहा है
- बिल्डिंग इंडेक्स
- सत्यापन से पहले लेखकों की प्रतीक्षा कर रहा है
- इंडेक्स सत्यापन:स्कैनिंग इंडेक्स
- इंडेक्स सत्यापन: टुपल्स को सॉर्ट करना
- इंडेक्स सत्यापन:स्कैनिंग टेबल
- पुराने स्नैपशॉट की प्रतीक्षा में
- मृत के रूप में चिह्नित करने से पहले पाठकों की प्रतीक्षा में
- छोड़ने से पहले पाठकों की प्रतीक्षा में
उदाहरण:
postgres=# create table test ( a int, b varchar(40), c timestamp );
CREATE TABLE
postgres=# insert into test ( a, b, c ) select aa, bb, cc from generate_series(1,10000000) aa, md5(aa::varchar) bb, now() cc;
INSERT 0 10000000
postgres=# CREATE INDEX idx ON test (b);
CREATE INDEX
सत्र 1:
postgres=# CREATE INDEX idx ON test (b);
[. . . waits for completion . . .]
सत्र 2:
postgres=# SELECT * FROM pg_stat_progress_create_index;
-[ RECORD 1 ]------+-------------------------------
pid | 19432
datid | 14187
datname | postgres
relid | 16405
index_relid | 0
command | CREATE INDEX
phase | building index: scanning table
lockers_total | 0
lockers_done | 0
current_locker_pid | 0
blocks_total | 93458
blocks_done | 46047
tuples_total | 0
tuples_done | 0
partitions_total | 0
partitions_done | 0
postgres=# SELECT * FROM pg_stat_progress_create_index;
-[ RECORD 1 ]------+---------------------------------------
pid | 19432
datid | 14187
datname | postgres
relid | 16405
index_relid | 0
command | CREATE INDEX
phase | building index: loading tuples in tree
lockers_total | 0
lockers_done | 0
current_locker_pid | 0
blocks_total | 0
blocks_done | 0
tuples_total | 10000000
tuples_done | 4346240
partitions_total | 0
partitions_done | 0
निष्कर्ष
PostgreSQL संस्करण 9.6 आगे कमांड निष्पादन के दौरान कुछ कमांड की प्रगति की रिपोर्ट करने की क्षमता रखता है। लंबे समय तक चलने वाले कमांड की प्रगति की जांच करने के लिए डीबीए, डेवलपर्स और उपयोगकर्ताओं के लिए यह वास्तव में एक अच्छी सुविधा है। यह रिपोर्टिंग क्षमता भविष्य में कुछ अन्य कमांडों के लिए विस्तारित हो सकती है। आप इस नई सुविधा के बारे में PostgreSQL दस्तावेज़ीकरण में अधिक पढ़ सकते हैं।