Pular para o conteúdo principal

Questão de Banco de Dados — PostgreSQL — VUNESP 2025

Banco de DadosPostgreSQL
Código
vu222889
Banca
VUNESP
Órgão
TJM SP
Ano
2025
Cargo
Ana CPDJ ( )
Considerando o sistema gerenciador de bancos de dados PostgreSQL 17.5, há um comando que possibilita a otimização de consultas feitas ao banco de dados, de forma que algumas partições de dados sejam excluídas pelo planejamento da consulta.   Tal comando é:
  1. ADEALLOCATE ...
  2. BSET ROLE ...
  3. CCLUSTER ...
  4. DSET enable_partition_pruning = on;
  5. ESET CONSTRAINTS ...
Revelar gabarito e comentário

GabaritoD — SET enable_partition_pruning = on;

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 partition pruning

Gabarito: letra D. O comando SET enable_partition_pruning = on; é o que ativa a poda de partições (partition pruning) no PostgreSQL, recurso que permite ao planejador de consultas excluir partições de tabelas particionadas que não serão acessadas, otimizando a execução. As demais alternativas tratam de outros comandos do PostgreSQL, sem relação com a exclusão de partições no planejamento.

O particionamento de tabelas é uma técnica de organização física dos dados em que uma tabela lógica é dividida em segmentos menores (partições), cada um armazenando um subconjunto de linhas com base em um critério (ex.: faixa de datas, lista de valores, hash). O benefício principal é a melhoria de desempenho: consultas que filtram pela chave de particionamento podem acessar apenas as partições relevantes, reduzindo drasticamente a quantidade de dados lidos do disco.

A poda de partições (partition pruning) é o mecanismo que torna isso possível. Durante o planejamento da consulta, o otimizador analisa as condições do WHERE e, se elas forem compatíveis com a chave de particionamento, elimina do plano de execução as partições que não atendem ao filtro. Por exemplo, em uma tabela vendas particionada por mês, uma consulta com WHERE data BETWEEN '2025-01-01' AND '2025-01-31' fará com que o planejador acesse apenas a partição de janeiro, ignorando as demais.

O parâmetro enable_partition_pruning controla exatamente esse comportamento. Quando definido como on (valor padrão), o planejador realiza a poda; quando off, a poda é desabilitada e todas as partições são consideradas no plano. A sintaxe SET enable_partition_pruning = on; é a forma de alterar esse parâmetro de configuração em uma sessão, conforme a documentação oficial do PostgreSQL.

É importante distinguir a poda de partições de outros conceitos de otimização, como o uso de índices. Enquanto os índices aceleram a busca dentro de uma tabela, a poda de partições evita até mesmo a leitura de partições inteiras. Ambos podem ser combinados: após a poda, os índices das partições restantes podem ser utilizados para acelerar ainda mais a consulta.

A pegadinha desta questão está em associar a otimização de consultas a comandos como CLUSTER ou DEALLOCATE, que têm finalidades distintas. O CLUSTER reorganiza fisicamente uma tabela com base em um índice, mas não exclui partições no planejamento. O DEALLOCATE libera uma declaração preparada. O SET ROLE altera o papel atual da sessão, e SET CONSTRAINTS controla a verificação de restrições em transações. Nenhum deles está relacionado à poda de partições.

Guarde a função de cada comando: é exatamente essa distinção que separa a alternativa correta das demais.

Otimização de consultas no PostgreSQL
  • 1Poda de partições (partition pruning)
    • SET enable_partition_pruning = on
    • Exclui partições no planejamento
    • Ex.: WHERE data BETWEEN → só partição de janeiro
  • 2Comandos que confundem
    • DEALLOCATE (libera prepared statement)
    • SET ROLE (altera papel da sessão)
    • CLUSTER (reorganiza fisicamente)
    • SET CONSTRAINTS (controle de restrições)
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

O comando DEALLOCATE é utilizado para liberar uma declaração preparada (prepared statement) no PostgreSQL, removendo-a da sessão. Não possui qualquer relação com a otimização de consultas por exclusão de partições. A confusão pode ocorrer por ambos serem comandos de gerenciamento de sessão, mas suas finalidades são completamente distintas.

Alternativa B — ❌ Incorreta

O comando SET ROLE altera o papel (role) atual da sessão no PostgreSQL, permitindo assumir as permissões de outro usuário. É um comando de controle de acesso, não de otimização de consultas. Não há qualquer vínculo com a exclusão de partições no planejamento.

Alternativa C — ❌ Incorreta

O comando CLUSTER reorganiza fisicamente uma tabela no PostgreSQL, ordenando suas linhas de acordo com um índice especificado. Embora possa melhorar o desempenho de consultas ao agrupar dados relacionados, não realiza a exclusão de partições no planejamento. A poda de partições é um mecanismo do otimizador, não uma operação de reorganização física.

Alternativa D — ✅ Correta ⟵ GABARITO

O comando SET enable_partition_pruning = on; ativa a poda de partições no PostgreSQL. Esse parâmetro de configuração permite que o planejador de consultas exclua partições de tabelas particionadas que não serão acessadas, otimizando a execução. É exatamente o que o enunciado descreve: "algumas partições de dados sejam excluídas pelo planejamento da consulta".

Alternativa E — ❌ Incorreta

O comando SET CONSTRAINTS controla a verificação de restrições (constraints) em transações no PostgreSQL, permitindo adiar a checagem de integridade referencial. Não está relacionado à otimização de consultas nem à exclusão de partições. A confusão pode surgir pelo prefixo SET, comum a vários comandos de configuração, mas a finalidade é totalmente diversa.

NÃO CAIA NESSA!

A banca explora a confusão entre comandos que começam com SET e o comando de otimização. SET ROLE, SET CONSTRAINTS e SET enable_partition_pruning têm sintaxes semelhantes, mas finalidades completamente diferentes. O candidato desatento pode escolher qualquer um deles por associação superficial. A chave é lembrar que a poda de partições é um parâmetro de otimização do planejador, não um comando de controle de acesso, transação ou reorganização física.

PEGA ESSA DICA!

Para questões sobre otimização no PostgreSQL, foque nos parâmetros que começam com enable_ (como enable_partition_pruning, enable_seqscan, enable_indexscan). Eles controlam diretamente o comportamento do otimizador. Já comandos como CLUSTER, REINDEX e VACUUM são operações de manutenção física, e SET ROLE/SET CONSTRAINTS são de controle de sessão/transação.

Gabarito: letra D

Link permanente: /questoes/vu222889