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
Entenda o Snapshot: a ferramenta de backup que não para seu serviço
Atualmente, o termo snapshot tem se popularizado por sua utilidade nas mais variadas Clouds. Este snapshot em questão funciona na sua casa, na sua infraestrutura local e até mesmo na
Entendendo CHAR, VARCHAR e TEXT no PostgreSQL
Ao modelar tabelas em PostgreSQL, uma das decisões mais comuns (e subestimadas) é a escolha do tipo de dado para armazenar texto. Embora CHAR, VARCHAR e TEXT sirvam ao mesmo
Descubra o poder do CouchDB: o banco de dados NoSQL orientado a documentos
CouchDB é um banco de dados NoSQL orientado a documentos. Utiliza JSON como formato de dados e JavaScript como linguagem de consulta. Diferente da maioria dos outros bancos de dados,







