I PostgreSQL kan mange DDL-kommandoer tage meget lang tid at udføre. PostgreSQL har mulighed for at rapportere fremskridt for DDL-kommandoer under kommandoudførelse. Siden PostgreSQL 9.6 har det været muligt at overvåge fremskridtene med at køre manuel VACUUM og autovakuum ved hjælp af et dedikeret systemkatalog (kaldet pg_stat_progress_vacuum).
PostgreSQL 12 har tilføjet understøttelse til at overvåge fremskridtene af et par flere kommandoer som CLUSTER, VACUUM FULL, CREATE INDEX og REINDEX.
I øjeblikket er statusrapporteringsfaciliteten kun tilgængelig for kommando som nedenfor.
- VACUUM-kommando
- KLUSTER-kommando
- VACUUM FULL-kommando
- CREATE INDEX-kommando
- REINDEX-kommando
Hvorfor er funktionen til statusrapportering i PostgreSQL vigtig?
Denne funktion er meget vigtig for operatører, når de udfører nogle langvarige operationer, fordi det er muligt ikke blindt at vente på, at en operation er færdig.
Dette er en meget nyttig funktion til at få lidt indsigt som:
- Hvor meget arbejde er der i alt
- Hvor meget arbejde, der allerede er udført
Funktionen til fremskridtsrapportering er også nyttig, når du laver analyse af præstationsarbejdsbelastning, dette har også vist sig at være nyttigt ved evaluering af VACUUM-jobbehandling for at justere parametre på systemniveau eller relationsniveau én gang afhængigt af belastningsmønsteret.
Understøttede kommandoer og systemkatalog
| DDL-kommando | Systemkatalog | Understøttet PostgreSQL-version |
| VAKUUM | pg_stat_progress_vacuum | 9.6 |
| VAKUUM FULD | pg_stat_progress_cluster | 12 |
| KLUSTER | pg_stat_progress_cluster | 12 |
| OPRET INDEKS | pg_stat_progress_create_index | 12 |
| REINDEX | pg_stat_progress_create_index | 12 |
Sådan overvåges fremskridtene af VACUUM-kommandoen
Når VACUUM-kommandoen kører, vil pg_stat_progress_vacuum-visningen indeholde en række for hver backend (inklusive autovacuum-arbejdsprocesser), der i øjeblikket støvsuger. Visningen til at kontrollere forløbet af at køre VACUUM- og VACCUM FULL-kommandoer er forskellig, fordi operationsfaserne for begge kommandoer er forskellige.
Betjeningsfaser for VACUUM-kommandoen
- Initialiserer
- Scanningsbunke
- Støvsugning af indekser
- Støvsugebunke
- Rydning af indekser
- Truncating heap
- Udfører endelig oprydning
Denne visning er tilgængelig i PostgreSQL 12, som giver følgende 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 | | |Eksempel:
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 | 18Statusrapportering for CLUSTER og VACUUM FULL
KLUSTER- og VACUUM FULL-kommandoen bruger de samme kodestier til relationsomskrivningen, så du kan kontrollere fremskridtene for begge kommandoer ved hjælp af view pg_stat_progress_cluster.
Denne visning er tilgængelig i PostgreSQL 12, og den viser følgende oplysninger:
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 | | | Driftsfaser af CLUSTER Command
- Initialiserer
- Seq-scanningsbunke
- Indeksscanningsbunke
- Sortering af tupler
- Skriver ny bunke
- Udskiftning af relationsfiler
- Genopbygning af indeks
- Udfører endelig oprydning
Eksempel:
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)Statusrapportering for CREATE INDEX og REINDEX
Når kommandoen CREATE INDEX eller REINDEX kører, vil visningen pg_stat_progress_create_index indeholde en række for hver backend, der i øjeblikket opretter indekser. Fremskridtsrapporteringsfunktionen gør det også muligt at spore smagen af CREATE INDEX og REINDEX. De interne udførelsesfaser af CREATE INDEX- og REINDEX-kommandoer er de samme, så du kan kontrollere status for begge kommandoer ved hjælp af den samme visning.
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 af CREATE INDEX / REINDEX
- Initialiserer
- Venter på forfattere før opbygning
- Bygningsindeks
- Venter på forfattere før validering
- Indeksvalidering:scanningsindeks
- Indeksvalidering: sortering af tupler
- Indeksvalidering:scanningstabel
- Venter på gamle snapshots
- Venter på læsere, før man markerer død
- Venter på læsere, før de dropper
Eksempel:
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 | 0Konklusion
PostgreSQL version 9.6 og fremefter har mulighed for at rapportere fremskridt for visse kommandoer under kommandoudførelse. Dette er en rigtig god funktion for DBA'er, udviklere og brugere til at kontrollere fremskridtene for langvarige kommandoer. Denne rapporteringsfunktion kan udvides til nogle andre kommandoer i fremtiden. Du kan læse mere om denne nye funktion i PostgreSQL-dokumentationen.