Uma das recomendações na prática do tuning no PostgreSQL como forma de melhorar o desempenho das tabelas com grandes quantidades de registros e especialmente com muitos acessos é a inserção de
Aíndices em todos os campos das tabelas.
Bvalores nulos em campos que compõem a cláusula WHERE ou que fazem parte de cláusulas ORDER BY, GROUP BY.
Cvalores nulos em campos que compõem o statement SELECT sem cláusula WHERE.
Díndices em campos que compõem a cláusula WHERE ou que fazem parte de cláusulas ORDER BY, GROUP BY.
Eíndices em todos os campos que compõem um statement SELECT DISTINCT e/ou cláusula CONSTRAINT.
Revelar gabarito e comentário▾
GabaritoD — índices em campos que compõem a cláusula WHERE ou que fazem parte de cláusulas ORDER BY, GROUP BY.
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”.
Tuning no PostgreSQL: índices e desempenho
Gabarito: letra D. A prática recomendada de tuning para tabelas com grandes volumes de registros e muitos acessos é criar índices nos campos que aparecem nas cláusulas WHERE, ORDER BY e GROUP BY — justamente o que a alternativa D afirma. Índices nessas colunas aceleram a localização e ordenação dos dados, reduzindo o tempo de resposta das consultas.
A banca testa o conhecimento básico sobre indexação: índices não devem ser criados indiscriminadamente — eles têm custo de manutenção e ocupam espaço. A recomendação padrão em qualquer SGBD relacional, incluindo o PostgreSQL, é indexar colunas usadas em condições de busca (WHERE), ordenação (ORDER BY) e agrupamento (GROUP BY).
Tuning PostgreSQL: índices: Onde criar índices (Campos em WHERE (filtro), Campos em ORDER BY (ordenação), Campos em GROUP BY (agrupamento)); Onde NÃO criar (Todos os campos da tabela, Todos os campos de SELECT DISTINCT, Campos de CONSTRAINT (já automáticos)); Custo dos índices (Espaço em disco, Manutenção em INSERT/UPDATE/DELETE)
Alternativa A — ❌ Incorreta
Criar índices em todos os campos da tabela é contraproducente: cada índice adicional exige atualização em operações de INSERT, UPDATE e DELETE, além de consumir mais espaço em disco. A indexação deve ser seletiva, focada nos campos que realmente trazem ganho de desempenho nas consultas.
Alternativa B — ❌ Incorreta
Inserir valores nulos em campos não melhora desempenho; pelo contrário, valores nulos podem complicar consultas e não são uma técnica de tuning. A recomendação é indexar campos usados em WHERE, ORDER BY, GROUP BY, não preenchê-los com nulos.
Alternativa C — ❌ Incorreta
Assim como na B, inserir valores nulos em campos de um SELECT sem WHERE não otimiza nada — a afirmação confunde conceitos. O tuning adequado envolve estruturas de acesso como índices, não a manipulação dos dados.
Alternativa D — ✅ Correta ⟵ GABARITO
É exatamente a prática consagrada: índices em campos que compõem a cláusula WHERE (filtro) ou que aparecem em ORDER BY e GROUP BY (ordenação/agrupamento) aceleram a execução das consultas. No PostgreSQL, isso é feito com comandos como CREATE INDEX sobre essas colunas.
Alternativa E — ❌ Incorreta
Indexar todos os campos de um SELECT DISTINCT ou de uma cláusula CONSTRAINT também é exagerado e ineficiente. Índices em CONSTRAINT (como PRIMARY KEY ou UNIQUE) já são criados automaticamente pelo sistema; adicionar índices extras em todos os campos do SELECT DISTINCT não é recomendado e pode piorar a performance de gravação.
PEGA ESSA DICA!
Na prática de tuning, foque nos índices que realmente serão usados pelo otimizador de consultas. Analise os planos de execução (EXPLAIN ANALYZE) para identificar quais colunas são as mais acessadas em filtros e ordenações. Lembre-se: índices demais podem ser piores do que índices de menos.