Questão de Banco de Dados — PostgreSQL — FUNDATEC 2025
Banco de Dados›PostgreSQL
Código
qg468566
Banca
FUNDATEC
Órgão
BRDE
Ano
2025
Nível
Superior
Cargo
Analista de Sistemas - Subárea Administração de Banco de Dados
Ao analisar um plano de execução no PostgreSQL usando EXPLAIN ANALYZE, um DBA observa uma operação Sequential Scan em uma tabela grande para uma query que deveria usar um índice. Qual é a causa mais provável para o otimizador ter escolhido o acesso sequencial completo em vez do índice?
AO parâmetro random_page_cost está configurado com um valor muito baixo.
BAs estatísticas do otimizador estão desatualizadas.
CO índice está corrupto e foi marcado como inválido.
DA query está filtrando uma grande porcentagem da tabela.
EA coluna indexada permite valores NULL.
Revelar gabarito e comentário▾
GabaritoD — A query está filtrando uma grande porcentagem da tabela.
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”.
PostgreSQL: Otimização de Consultas com EXPLAIN ANALYZE
Gabarito: letra D. A causa mais provável para o otimizador escolher um Sequential Scan em vez de um Index Scan é a recuperação de uma grande proporção das linhas da tabela. Quando a porcentagem de linhas filtradas é alta, o custo do índice (acesso aleatório) supera o custo da varredura sequencial, e o PostgreSQL opta pela leitura completa.
Alternativa A — ❌ Incorreta
O parâmetro random_page_cost baixo torna o acesso aleatório mais barato, favorecendo o uso de índices. Um valor baixo não levaria a Sequential Scan, mas sim o contrário.
Alternativa B — ❌ Incorreta
Estatísticas desatualizadas podem sim fazer o otimizador tomar decisões erradas, mas a pergunta pede a causa mais provável. A alternativa D é mais comum e direta. Além disso, o enunciado diz que "deveria usar um índice", sugerindo que o índice existe e é válido; estatísticas desatualizadas poderiam levar a subestimação do número de linhas, mas também poderiam levar a superestimação. A opção D é a razão clássica: quando a query retorna muitas linhas, sequential scan é preferível.
Alternativa C — ❌ Incorreta
Um índice corrupto e marcado como inválido não seria considerado pelo otimizador; ele simplesmente não estaria disponível, e o Sequential Scan seria a única opção. Porém, o enunciado diz "deveria usar um índice", indicando que o índice existe e é válido. Além disso, corrupção é causa menos provável.
Alternativa D — ✅ Correta ⟵ GABARITO
Quando a query filtra uma grande porcentagem da tabela (ex.: >5-10%), o custo do acesso sequencial é menor que o custo de acessos aleatórios via índice. O otimizador de custos do PostgreSQL estima o número de linhas e compara os custos, escolhendo o plano mais barato.
Alternativa E — ❌ Incorreta
Colunas com valores NULL podem ser indexadas em PostgreSQL (B-tree indexa NULLs). A presença de NULLs não impede o uso do índice.
NÃO CAIA NESSA!
A banca testa o conhecimento de que índices não são sempre melhores que varreduras sequenciais. O otimizador avalia o custo baseado na seletividade da query. Muitos alunos pensam que índices são sempre superiores, mas para grandes volumes de dados recuperados, o sequencial é mais eficiente.