Questão de Banco de Dados — PostgreSQL — VUNESP 2025
- Código
- vu222889
- Banca
- VUNESP
- Órgão
- TJM SP
- Ano
- 2025
- Cargo
- Ana CPDJ ( )
- ADEALLOCATE ...
- BSET ROLE ...
- CCLUSTER ...
- DSET enable_partition_pruning = on;
- ESET CONSTRAINTS ...
GabaritoD — SET enable_partition_pruning = on;
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.
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.
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.
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.
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".
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.
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.
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