Otimização de desempenho no PostgreSQL
Gabarito: letra C. O conjunto mais apropriado para otimizar o planejador de consultas em um cluster PostgreSQL com degradação de performance é ajustar parâmetros como random_page_cost (considerando o tipo de armazenamento), effective_cache_size, work_mem, aumentar default_statistics_target para colunas críticas e executar ANALYZE regularmente. Essa combinação melhora a qualidade dos planos de execução, alinhando o planejador às características do hardware e às estatísticas atualizadas.
Ação de Otimização | Descrição | Impacto no Planejador | Recomendação |
|---|
Ajustar random_page_cost | Configurar custo de leitura aleatória conforme o tipo de armazenamento (SSD vs. HDD) | Alinha o planejador ao hardware, favorecendo varreduras por índice em SSDs | Essencial para planos eficientes |
Configurar effective_cache_size | Estimar o tamanho do cache do sistema operacional para o PostgreSQL | Permite ao planejador avaliar corretamente o custo de varreduras sequenciais | Deve refletir a memória disponível |
Ajustar work_mem | Definir memória para operações de ordenação e hash | Evita derramamento para disco em consultas complexas | Aumentar gradualmente conforme necessidade |
Aumentar default_statistics_target | Ampliar amostragem de estatísticas para colunas críticas | Melhora a precisão das estimativas de cardinalidade | Aplicar seletivamente em colunas com dados desbalanceados |
Executar ANALYZE regularmente | Atualizar estatísticas das tabelas | Garante que o planejador use dados recentes para decisões | Automatizar com autovacuum ou agendamento |
Alternativa A — ❌ Incorreta
Desabilitar o uso de índices globalmente com enable_indexscan=off força o planejador a evitar varreduras por índice, o que geralmente piora o desempenho, especialmente em consultas seletivas. Não é uma otimização recomendada para degradação geral.
Alternativa B — ❌ Incorreta
VACUUM FULL é uma operação pesada que compacta tabelas fisicamente, mas deve ser usada com moderação, não diariamente durante horário comercial, pois causa bloqueios intensos. Além disso, não aborda diretamente planos subótimos.
Alternativa C — ✅ Correta
Ajustar random_page_cost (custo de leitura aleatória) conforme o storage (SSD vs. HDD), effective_cache_size (tamanho de cache do sistema), work_mem (memória para ordenação e hash), e aumentar default_statistics_target para colunas críticas melhora a precisão das estatísticas. Executar ANALYZE regularmente mantém as estatísticas atualizadas, permitindo que o planejador escolha planos eficientes.
Alternativa D — ❌ Incorreta
Converter tabelas para UNLOGGED sacrifica a durabilidade (dados podem ser perdidos em falha) e não é uma solução geral para otimização de consultas. Adequado apenas para tabelas temporárias ou de baixa criticidade.
Alternativa E — ❌ Incorreta
Desabilitar o autovacuum e executar VACUUM manualmente apenas mensalmente pode levar ao acúmulo de tuplas mortas e estatísticas desatualizadas, degradando ainda mais o desempenho. O autovacuum é essencial para manutenção automática.
Gabarito: letra C