Tempo de Execução

Para dar suporte à comprovação da Hipótese de Pesquisa 1, executamos 5000 consul- tas, usando tanto a técnica padrão do PostgreSQL quanto a versão modificada desse sistema com o método proposto, e acumulamos o tempo de execução de todas elas em quatro partes: até 1250, 2500, 3750 e 5000 consultas. Os resultados obtidos por meio desse experimento são mostrados

Tabela 7 – Tempo acumulado de execução de 1250, 2500, 3750 e 5000 consultas quando executadas no PostgreSQL não modificado e esse sistema modificado com a nossa proposta.

Abordagem/

Tempo acumulado (min) ≤ 1250 ≤ 2500 ≤ 3750 ≤ 5000

Método Proposto 277.09389 598.76837 886.04205 1182.96412 PostgreSQL 285.14849 612.49828 906.34336 1210.44504 Diferença 8.05460 1.3,72991 20,30131 27,48092

na Tabela 7. A última linha indica a diferença entre o resultado obtido por meio do PostgreSQL sem modificação e com modificação.

Observando os valores apresentados, chegamos à conclusão de que o tempo de executar as mesmas consultas no PostgreSQL usando o nosso método proposto e o mesmo sistema usando a técnica tradicional, que é baseada em histogramas, é aproximadamente 2, 5% menor, o que representa uma economia próxima de 30 minutos. Ou seja, as mesmas consultas demoraram 30 minutos a menos para serem executadas no sistema com o nosso método. Em consequência, é concebível dizer que essa economia está relacionada com a mudança do PE escolhido para executar algumas consultas. Isto é, pelo motivo de que as estimativas de cardinalidades estarem mais acuradas, as estimativas de custo dos PEs equivalentes de uma dada consulta também estão, portanto a escolha do PE com menor custo anterior à execução se mostra a opção correta no tempo de execução. Para comprovar esse fato, escolhemos a consulta que apresentou o maior ganho de desempenho que é apresentada a seguir.

SELECT *

FROM cast_info CI, movie_info MI, title T

WHERE CI.movie_id = T.id AND MI.movie_id=T.id AND CI.role_id > 1 AND MI.info_type_id > 1 AND T.production_year = 1996;

Em síntese, essa consulta possui duas operações de junções e três de seleção. Entre os planos avaliados pelo PostgreSQL usando sua técnica padrão de estimativas, aquele com o menor custo estimado se encontra na Figura 38. Nesse plano, as operações de junção são implementadas pelo algoritmo Hash Join, que aplica uma estrutura de dados hash para realizar a operação. Para realizar as operações de seleção, realiza-se uma varredura sequencial (SeqScan) das três relações CI, MI e T .

Por outro lado, a Figura 39 apresenta o PE escolhido pelo PostgreSQL utilizando o método proposto para calcular as estimativas. Neste, as mesmas operações de junção são implementadas pelo algoritmo Nested Loop, que aplica uma iteração nos dados para realizar a

Figura 38 – PE escolhido pelo PostgreSQL usando a sua técnica de estimativas padrão para a consulta com maior ganho de desempenho.

operação. Ao contrário de fazer uma varredura sequencial nos dados para realizar as operações de seleção, esse plano usa as estruturas de índices existentes para realizá-las. De modo geral, ao usar esses índices, as operações de seleção têm um custo menor associado, o que impactou no desempenho melhor desse PE.

Muito embora o desempenho geral usando o PostgreSQL modificado ter sido superior ao sem modificação, é possível observar que o ganho tido foi em torno de no máximo 2, 5%. Com o intuito de analisar o porquê dessa situação, vamos analisar a seguinte consulta SQL que apresentou uma piora no seu tempo de execução.

SELECT *

FROM cast_info CI, movie_companies MC, title T WHERE CI.movie_id = T.id AND MC.movie_id=T.id AND

MC.company_type_id = 1 AND T.kind_id = 1;

Esta consulta é composta por duas operações de junção e duas de seleção. A Figura 40 ilustra o PE escolhido quando o PostgreSQL usa seu estimador padrão baseado em histogramas, enquanto que a Figura 41 mostra o PE escolhido quando o método proposto é empregado. Observando os PEs apresentados, é possível detectar que a única diferença entre eles

Figura 39 – PE escolhido pelo PostgreSQL usando o método proposto para a consulta com maior ganho de desempenho.

é a maneira pela qual as operações de junção são realizadas. Na verdade, a ordem de aplicação dessas operações. No primeiro, a ordem escolhida foi CI ./ (MC ./ T ). Em contrapartida, o segundo escolheu a ordem (CI ./ MC) ./ T . Como apresentado na Tabela 2, a operação de junção é associativa, ou seja, essas duas operações são equivalentes.

O plano escolhido usando a técnica padrão do PostgreSQL é esperado ter um menor custo tendo em vista que as duas operações de seleção vão diminuir o trabalho necessário para gerar o resultado da junção entre MC e T . O problema que ocorreu para o PostgreSQL não ter escolhido esse plano quando usou o método proposto foi que as estimativas de cardinalidade para as operações de seleção não foram tão acuradas quanto ao do PostgreSQL usando histogramas. Como ressaltado na apresentação desta técnica, os histogramas produzem estimativas com bastante qualidade para operações unidimensionais, como é o caso apresentado. O seu problema é nos casos em que é necessário estimar seleções em mais de um atributo, pois os histogramas multidimensionais não apresentam uma viabilidade para serem usados na prática. Aprofundar o estudo sobre como superar essa dificuldade do método proposto é uma possível direção para trabalhos futuros, assim como avaliar a possibilidade de se considerar a incerteza no processo de geração das estimativas.

Figura 40 – PE escolhido pelo PostgreSQL usando a sua técnica de estimativas padrão para a consulta com maior perda de desempenho.

Figura 41 – PE escolhido pelo PostgreSQL usando o método proposto para a consulta com maior perda de desempenho.

Figura 42 – Diferença entre os tempos de execução das consultas com maior ganho e perda usando a técnica padrão e o método proposto.

no tempo de execução das duas consultas mostradas acima.

Observando o gráfico, é possível observar que a primeira consulta, a de maior ganho, apresenta um tempo maior que 40K quando o PE escolhido é aquele estimado usando a técnica padrão. Quando o método proposto é utilizado, esse tempo cai para uma ordem de aproximadamente 5K. Em relação à segunda consulta, temos que ela possui um tempo de execução da ordem de 70K utilizando a técnica padrão, enquanto que usando o método proposto esse tempo sobe para uma ordem de 160K. A conclusão que podemos chegar é que o tempo ganho na primeira consulta é diluído pela perda da segunda, o que justifica o ganho geral de desempenho não ter sido superior à 2, 5%.