Analista do Ministério Público - Especialidade: Desenvolvimento de Sistemas
Um Ministério Público Estadual tem posse de uma base de dados intitulada processos, criada no PostgreSQL 11+, com condições ideais, majoritariamente append-only nas quais são utilizados planos do tipo index - only scan. Contudo, ainda apresenta muitos heap fetches quando comandos são executados com EXPLAIN (ANALYZE, BUFFERS). A ação que tende a viabilizar a leitura somente pelo índice em cenário consistente é
Aalterar o nível de isolamento para REPEATABLE READ na sessão de leitura, pois isso torna as tuplas implicitamente visíveis ao índice.
Bforçar enable_seqscan = off na sessão, pois isso converte o plano em index - only scan, evitando leituras no heap.
Cajustar random_page_cost para reduzir a penalidade de acesso aleatório e induzir o otimizador a evitar o heap.
Dexecutar VACUUM (rotineiro/automático bem ajustado) para aumentar a marcação all - visible all-visible e reduzir a necessidade de visitar o heap.
Ecriar um índice B-Tree com INCLUDE nas colunas projetadas, pois isso elimina a dependência de visibilidade de tuplas no heap.
Revelar gabarito e comentário▾
GabaritoD — executar VACUUM (rotineiro/automático bem ajustado) para aumentar a marcação all - visible all-visible e reduzir a necessidade de visitar o heap.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Index-Only Scan e Heap Fetches no PostgreSQL
Gabarito: letra D. O VACUUM é a ação correta porque ele atualiza o visibility map (mapa de visibilidade), marcando páginas como "all-visible". Com isso, o index-only scan pode dispensar a verificação do heap para confirmar a visibilidade das tuplas, reduzindo os heap fetches. As demais alternativas ou não eliminam a necessidade de visitar o heap ou alteram parâmetros que não atacam a causa raiz (falta de marcação de visibilidade).
O cenário descrito é uma tabela append-only com planos index-only scan, mas ainda com muitos heap fetches. Isso ocorre porque, mesmo quando o índice contém todas as colunas necessárias, o PostgreSQL precisa verificar no heap se a tupla é visível para a transação atual. O visibility map informa se uma página inteira contém apenas tuplas visíveis a todas as transações. Quando uma página está marcada como "all-visible", o index-only scan pode pular a ida ao heap. O VACUUM (rotineiro ou automático) é o processo que atualiza esse mapa.
Ação
Descrição
Efeito sobre Heap Fetches
Correta?
A) Alterar isolamento para REPEATABLE READ
Torna tuplas implicitamente visíveis ao índice
Não elimina heap fetches (visibilidade controlada por MVCC, não por isolamento)
❌
B) Forçar enable_seqscan = off
Converte plano em index-only scan, evitando leituras no heap
Não garante index-only scan; pode resultar em index scan comum com heap fetches
❌
C) Ajustar random_page_cost
Reduz penalidade de acesso aleatório para induzir otimizador a evitar heap
Não elimina heap fetches (problema é visibilidade, não custo)
❌
D) Executar VACUUM (rotineiro/automático)
Aumenta marcação all-visible no visibility map
Reduz necessidade de visitar heap para verificar visibilidade
✅
E) Criar índice B-Tree com INCLUDE
Elimina dependência de visibilidade de tuplas no heap
Não elimina heap fetches (visibilidade ainda precisa ser verificada)
❌
Alternativa A — ❌ Incorreta
Alterar o nível de isolamento para REPEATABLE READ não torna tuplas implicitamente visíveis ao índice. No MVCC do PostgreSQL, a visibilidade é controlada por flags de transação (xmin/xmax) e pelo visibility map, independentemente do nível de isolamento. REPEATABLE READ apenas evita ler mudanças de transações concorrentes, mas não elimina heap fetches.
Alternativa B — ❌ Incorreta
Forçar enable_seqscan = off apenas desabilita varreduras sequenciais, mas não garante que o plano seja index-only scan. O otimizador pode escolher um index scan comum, que também faz heap fetches para cada linha encontrada. A redução de heap fetches depende da visibilidade, não da desabilitação de scans sequenciais.
Alternativa C — ❌ Incorreta
Ajustar random_page_cost altera o custo relativo de acesso aleatório, influenciando a escolha entre index scan e sequential scan. Se o plano já é index-only scan, o custo de acesso aleatório já é baixo; o problema não é o custo, mas a necessidade de verificar a visibilidade no heap. Reduzir random_page_cost não elimina heap fetches quando a visibilidade não está marcada.
Alternativa D — ✅ Correta ⟵ GABARITO
O VACUUM (rotineiro ou automático bem ajustado) percorre as páginas e atualiza o visibility map, marcando como "all-visible" aquelas em que todas as tuplas são visíveis a todas as transações. Com isso, o index-only scan pode confiar no visibility map e evitar visitar o heap para verificar a visibilidade, reduzindo heap fetches. Em tabelas append-only, o VACUUM é especialmente importante porque as páginas novas ainda não foram marcadas.
Alternativa E — ❌ Incorreta
Criar um índice B-Tree com INCLUDE (índice de cobertura) adiciona colunas ao índice para evitar buscar dados do heap apenas para obter valores. No entanto, isso não elimina a dependência de visibilidade: mesmo com todas as colunas no índice, o PostgreSQL ainda precisa verificar se a tupla é visível. Se a página não estiver marcada como "all-visible", será necessário um heap fetch para confirmar a visibilidade. O covering index reduz heap fetches para dados, mas não para visibilidade.
PEGA ESSA DICA!
Em provas de PostgreSQL, lembre-se que index-only scan só evita heap fetches se o visibility map estiver atualizado. O VACUUM é a ferramenta que faz isso. Questões sobre desempenho com append-only frequentemente testam esse conceito.