ANC - Analista em Computação - Ênfase em Suporte de Banco de Dados
Assinale a alternativa correta sobre otimização de código SQL (tuning) no PostgreSQL 14.
ACaso o número de trabalhadores livres não seja suficiente, o líder espera até que um número suficiente de trabalhadores esteja disponível para executar o plano.
BEm operações de merge join, o lado de dentro não pode executar em paralelo.
CO usuário precisa especificar que uma query deve ser executada em paralelo.
DQueries que modificam ou inserem dados não podem ser executadas em paralelo.
ESuporta agregação em paralelo, executada em dois níveis, o primeiro em paralelo, e o segundo individualmente pelo líder.
Revelar gabarito e comentário▾
GabaritoE — Suporta agregação em paralelo, executada em dois níveis, o primeiro em paralelo, e o segundo individualmente pelo líder.
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”.
Otimização de código SQL (tuning) no PostgreSQL 14
Gabarito: Letra E. No PostgreSQL 14, a agregação em paralelo é executada em dois níveis: primeiro os workers processam partes dos dados em paralelo, gerando resultados parciais; depois o líder (leader) combina esses resultados parciais em um resultado final. Esse comportamento é nativamente suportado pelo banco, sem necessidade de sintaxe especial, e é uma das técnicas de tuning para consultas com grande volume de dados.
A banca explora o conhecimento prático sobre como o paralelismo funciona no PostgreSQL 14. Vamos analisar cada alternativa:
Agregação em paralelo (PostgreSQL 14): 1º nível (workers) (Processam partes dos dados, Geram resultados parciais); 2º nível (líder) (Combina resultados parciais, Resultado final); Características (Suporte nativo, Sem sintaxe especial, Para grande volume de dados)
Alternativa A — ❌ Incorreta
Afirma que o líder espera até que um número suficiente de trabalhadores esteja disponível. Na verdade, se não houver workers livres suficientes, o PostgreSQL pode executar a consulta com menos workers ou até mesmo em série (sem paralelismo), mas não fica esperando indefinidamente.
Alternativa B — ❌ Incorreta
Diz que em operações de merge join o lado de dentro não pode executar em paralelo. No PostgreSQL 14, os merge joins podem ser paralelizados; os workers podem atuar em cada lado da junção, desde que os planos permitam.
Alternativa C — ❌ Incorreta
Afirma que o usuário precisa especificar que uma query deve ser executada em paralelo. Na realidade, o PostgreSQL decide automaticamente, com base no custo estimado e na disponibilidade de workers, se a consulta será paralela. O usuário pode influenciar via parâmetros (ex.: max_parallel_workers_per_gather), mas não é obrigatório especificar.
Alternativa D — ❌ Incorreta
Alega que queries que modificam ou inserem dados não podem ser executadas em paralelo. O PostgreSQL permite paralelismo em algumas operações DML, como INSERT ... SELECT e CREATE TABLE AS, desde que a parte de consulta (SELECT) seja paralela. Portanto, a afirmação é falsa por ser absoluta.
Alternativa E — ✅ Correta ⟵ GABARITO
Descreve corretamente a agregação em paralelo: os workers executam a primeira fase (agregação parcial) em paralelo, e o líder executa a segunda fase (agregação final) de forma individual, consolidando os resultados. Esse é um recurso nativo do PostgreSQL 14.
PEGA ESSA DICA!
Na prova, lembre-se de que o PostgreSQL distribui a execução entre workers e líder em dois momentos: fase paralela (workers) e fase de consolidação (líder). Esse padrão aparece em agregações, junções e varreduras paralelas.