I PostgreSQL kan många DDL-kommandon ta mycket lång tid att köra. PostgreSQL har förmågan att rapportera utvecklingen av DDL-kommandon under kommandoexekvering. Sedan PostgreSQL 9.6 har det varit möjligt att övervaka framstegen för att köra manuellt VACUUM och autovacuum med hjälp av en dedikerad systemkatalog (kallad pg_stat_progress_vacuum).
PostgreSQL 12 har lagt till stöd för att övervaka framstegen för några fler kommandon som CLUSTER, VACUUM FULL, CREATE INDEX och REINDEX.
För närvarande är funktionen för förloppsrapportering endast tillgänglig för kommandon enligt nedan.
- VACUUM-kommando
- KLUSTER-kommando
- VACUUM FULL-kommandot
- CREATE INDEX-kommandot
- REINDEX-kommando
Varför är funktionen för framstegsrapportering i PostgreSQL viktig?
Denna funktion är mycket viktig för operatörer när de utför långa operationer, eftersom det är möjligt att inte blint vänta på att en operation ska avslutas.
Det här är en mycket användbar funktion för att få lite insikt som:
- Hur mycket arbete totalt finns
- Hur mycket arbete som redan gjorts
Funktionen för förloppsrapportering är också användbar när man gör analys av prestandaarbetsbelastning, detta har också visat sig vara användbart för att utvärdera VACUUM-jobbbearbetning för att justera parametrar på systemnivå eller relationsnivå en gång beroende på belastningsmönster.
Kommandon som stöds och systemkatalog
| DDL-kommando | Systemkatalog | PostgreSQL-version som stöds |
| VAKUUM | pg_stat_progress_vacuum | 9.6 |
| VAKUUM FULL | pg_stat_progress_cluster | 12 |
| KLUSTER | pg_stat_progress_cluster | 12 |
| SKAPA INDEX | pg_stat_progress_create_index | 12 |
| REINDEX | pg_stat_progress_create_index | 12 |
Hur man övervakar framstegen för VACUUM-kommandot
När VACUUM-kommandot körs kommer vyn pg_stat_progress_vacuum att innehålla en rad för varje backend (inklusive processer för autovacuum) som för närvarande dammsuger. Vyn för att kontrollera framstegen för att köra VACUUM- och VACCUM FULL-kommandon är olika eftersom operationsfaserna för båda kommandona är olika.
Operationsfaser för VACUUM-kommandot
- Initialiserar
- Skanningshög
- Dammsugningsindex
- Dammsugningshög
- Rensa upp index
- Truncating heap
- Utför slutstädning
Denna vy är tillgänglig i PostgreSQL 12 som ger följande information:
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 | | |Exempel:
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 1666666Session 1:
postgres=# vacuum verbose test;
[. . . waits for completion . . .]Session 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 | 18Förloppsrapportering för CLUSTER och VACUUM FULL
KLUSTER- och VACUUM FULL-kommandot använder samma kodsökvägar för relationsomskrivningen, så att du kan kontrollera förloppet för båda kommandona med hjälp av vyn pg_stat_progress_cluster.
Denna vy är tillgänglig i PostgreSQL 12 och den visar följande information:
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 | | | Operationsfaser för CLUSTER Command
- Initialiserar
- Seq scanning heap
- Indexsökningshög
- Sortera tuplar
- Skriver ny hög
- Byte av relationsfiler
- Återuppbyggnad av index
- Utför slutstädning
Exempel:
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. Session 1:
postgres=# cluster verbose test using idx1;
[. . . waits for completion . . .]Session 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)Förloppsrapportering för CREATE INDEX och REINDEX
När kommandot CREATE INDEX eller REINDEX körs kommer vyn pg_stat_progress_create_index att innehålla en rad för varje backend som för närvarande skapar index. Funktionen för förloppsrapportering gör det möjligt att spåra även smakerna av CREATE INDEX och REINDEX. De interna exekveringsfaserna för CREATE INDEX- och REINDEX-kommandona är desamma, så du kan kontrollera förloppet för båda kommandona med samma vy.
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 | | | Driftsfaser för CREATE INDEX / REINDEX
- Initialiserar
- Väntar på författare innan bygget
- Byggindex
- Väntar på skribenter innan validering
- Indexvalidering:skanningsindex
- Indexvalidering: sortering av tuplar
- Indexvalidering:skanningstabell
- Väntar på gamla ögonblicksbilder
- Väntar på läsare innan de markeras som döda
- Väntar på läsare innan de släpper
Exempel:
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 INDEXSession 1:
postgres=# CREATE INDEX idx ON test (b);
[. . . waits for completion . . .]Session 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 | 0Slutsats
PostgreSQL version 9.6 och framåt har förmågan att rapportera framstegen för vissa kommandon under kommandoexekveringen. Detta är en riktigt trevlig funktion för DBA:er, utvecklare och användare för att kontrollera hur långa kommandon fortskrider. Den här rapporteringsmöjligheten kan utökas för vissa andra kommandon i framtiden. Du kan läsa mer om denna nya funktion i PostgreSQL-dokumentationen.