Monitorando o progresso de comandos no PostgreSQL 16
A partir da versão 16, o PostgreSQL passou a oferecer a possibilidade de monitorar o progresso de alguns comandos.
Em outras palavras, agora é possível obter informações intermediárias sobre a execução de determinadas operações.
Podemos identificar quais processos estão ativos utilizando a consulta abaixo:
SELECT pid, query
FROM pg_stat_activity
WHERE state = 'active';Atualmente, é possível verificar o progresso detalhado dos seguintes comandos:
- Comandos de manutenção: ANALYZE, VACUUM, VACUUM FULL e CLUSTER
- Comandos de índices: CREATE INDEX, REINDEX
- Backups/Replicação:BASE BACKUP
- Backup/Restore: COPY
Por enquanto, instruções SELECT não fornecem informações detalhadas de progresso.
Na prática
Cada tipo de comando possui um conjunto específico de informações de progresso, que podem ser visualizadas por meio de views próprias:
ANALYZE: pg_stat_progress_analyze
VACUUM: pg_stat_progress_vacuum
VACUUM FULL, CLUSTER: pg_stat_progress_cluster
CREATE INDEX, REINDEX: pg_stat_progress_create_index
BASE BACKUP:pg_stat_progress_basebackup
COPY:pg_stat_progress_copy
Todos os tipos de comandos, exceto o COPY, exibem uma coluna de fase (phase), já que, na maioria dos casos, há várias etapas envolvidas na execução.
O progresso de CREATE INDEX é mais complexo, principalmente quando se utiliza a opção CONCURRENTLY.
A fase mais demorada costuma ser a de construção dos índices, que pode levar vários minutos dependendo do tamanho da tabela.
Após a construção com CONCURRENTLY, podem ocorrer uma ou mais situações de espera, indicando que o processo está bloqueado por outras operações em execução. Esse bloqueio pode ser identificado pela coluna current_locker_pid.
No caso do BASE BACKUP, a fase mais longa é a de transmissão dos arquivos do banco de dados.
O progresso é medido em bytes e pode ser calculado assim:
SELECT pid, phase,
100.0*((backup_streamed*1.0)/backup_total) AS "progress%"
FROM pg_stat_progress_basebackup;Mesmo que o comando COPY não exiba a fase, o progresso pode ser estimado da seguinte forma:
COPY FROM
SELECT (SELECT relname FROM pg_class WHERE oid = relid),
100.0*((bytes_processed*1.0)/bytes_total) AS "progress %"
FROM pg_stat_progress_copy;COPY TO
SELECT relname,
100.0*((tuples_processed*1.0)/(case reltuples WHEN 0 THEN 10 WHEN -1
THEN 10 ELSE reltuples END))
AS "progress %"
FROM pg_stat_progress_copy JOIN pg_class on oid = relid;Todos os comandos, com exceção do BASE BACKUP, exibem as colunas `datid` e `datname`, que indicam, respectivamente, o ID e o nome do banco de dados.
About author
Você pode gostar também
PostgreSQL em Kubernetes: funciona?
Bom, se tem uma coisa pela qual eu sempre torci o nariz é a utilização de bancos de dados relacionais sem soluções de microserviços. Quem conhece um pouco sabe que
Entenda o Log Binário do MySQL e suas aplicações práticas
O log binário do MySQL é, por vezes, mal compreendido, principalmente por usuários de outros bancos de dados. Nesta postagem pretendo abordar alguns aspectos desse importante mecanismo. Write-ahead logging? Também
Como lidar com dados duplicados no PostgreSQL usando a coluna de sistema ctid
Você que utiliza PostgreSQL, já deve ter se deparado com o problema dos dados duplicados. É possível que em uma tabela existam campos que contenham valores repetidos e sua necessidade







