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 Middleware: A espinha dorsal da conectividade digital
No cenário tecnológico atual, a conectividade é a espinha dorsal que sustenta nossa vida digital. Imagine um ecossistema complexo de aplicativos, serviços e dispositivos, todos operando em conjunto perfeito. Essa
O ‘Elefante’ faz aniversário.
No dia 8 de julho de 2024, o PostgreSQL comemora informalmente 28 anos de vida. O evento que serviu de base para a escolha desta data foi que em 8
Como resolver o problema de deadlock em aplicações Java com PostgreSQL
Eis que o log da sua aplicação, num determinado INSERT, por exemplo em Java, mostra o seguinte erro: org.postgresql.util.PSQLException: ERROR: deadlock detected Trata-se do famoso e conhecido “deadlock”,mas aqui falaremos







