Verificamos que neste caso o uso de índice não ajudou muito. A adição de um possível índice inclusive aumentou o tempo da consulta e o QUERY COST

create index idx_lineitem_shipdate on LINEITEM(l_shipdate);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 17s

Tempo com índice: 22,8s

Nesta consulta o tempo da consulta já estava bem pequeno. mas ainda sim era realizado um FULL SCAN na tabela PART Logo, resolvemos criar o seguinte índice (que diminuiu bastante o QUERY COST):

create index idx_part_join on PART(p_partkey p_size);

Depois ainda criamos o seguinte índice(que também melhorou um pouco mais o tempo de execução e o QUERY COST):

create index idx_partsupp_supplycost on PARTSUPP(ps_supplycost);

Poderia ser criado também o índice:

create index idx_region_name on REGION(r_name);

Mas pelo fato da tabela REGION ter poucos registros a vantagem não seria tão grande

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 0,17s

Tempo com índice: 0,04s

Pelo fato da tabela ORDERS não ter nenhum índice, o óbvio foi criar o seguinte índice:

create index idx_order_conditions on ORDERS(o_custkey, o_orderkey, o_orderdate);

Ele diminuiu o QUERY COST mas não houve melhora no tempo. Em alguns casos a consulta sem índice chegou a rodar mais rápido

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: De 3,9s a 6s

Tempo com índice: 4,9s

Novamente uma consulta na tabela ORDERS Pelo fato de não possuir índices, escolhemos o seguinte:

create index idx_order_orderdate on ORDERS(o_orderdate);

O índice diminuiu o QUERY COST e também o tempo da consulta

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 2,5s

Tempo com índice: 1,5s

Esta é mais uma consulta que usa a tabela ORDERS que não possui nenhum índice. A solução mais significativa foi colocar um indice nos campos de ORDERS que foram usados no WHERE Assim conseguimos diminuir o tempo da consulta e também o QUERY COST, pois deixamos de fazer um FULL SCAN na tabela ORDERS Desta forma:

create index idx_order_conditions on ORDERS(o_custkey, o_orderkey, o_orderdate);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 3s

Tempo com índice: 1,5s

Nesta consulta não houve nenhum índice que fosse capaz de diminuir o QUERY COST No entanto, criamos o seguinte índice:

create index idx_lineitem_conditions on LINEITEM(l_shipdate, l_discount, l_quantity);

Apesar desse índice ter mantido o custo igual, o tempo da consulta diminuiu

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 3s

Tempo com índice: 1,65s

Verificamos que a tabela ORDERS não possuia nenhum índice criado. com isso foi criado o seguinte índice:

create index idx_order_join on ORDERS(o_custkey, o_orderkey);

Que mostrou-se eficiente, reduzindo o custo da query em quase 80%

• Execution Plan

• Execution Plan com índice criado

Tempo sem índice: 14s - 17s

Tempo com índice: 2,6 - 3,6s

Mais uma vez a tabela ORDERS é a principal responsavel pelo tempo da consulta. O fato da tabela não possuir nenhum índice aumenta muito o tempo da consulta pois é preciso fazer um FULL SCAN A simples adicão de um indice usando as mesma colunas usadas nas condições de junção, já diminuiu bastante o tempo. No entanto, adicionamos também um índice na tabela PART que diminuiu mais um pouco o tempo. Os seguintes índices foram adicionados:

create index idx_order_conditions on ORDERS(o_custkey, o_orderkey, o_orderdate);
create index idx_part_type on PART(p_type);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 6s

Tempo com índice: 2,6s

A consulta não rodou em menos de 60 segundos (deu TIMEOUT) Pelo fato da tabela ORDERS não possuir nenhum índice criado. A consulta tornava-se muito custosa com isso foi criado o seguinte índice:

create index idx_order_orderkey on ORDERS(o_orderkey)

Explain

• Execution Plan com índice criado

Tempo sem índice: Deu Timeout (mais de 60s)

Tempo com índice: 12,6s

Como já vimos, a tabela ORDERS não possui nenhum índice criado. com isso foi criado o seguinte índice:

create index idx_order_orderdate on ORDERS(o_orderdate);

Desta forma o SGBG consegue fazer um RANGE SCAN nesta consulta, conforme mostrado no EXECUTION PLAN

• Execution Plan

• Execution Plan com índice criado

Tempo sem índice: De 2,9s a 4,4s

Tempo com índice: De 2s a 2,2s

Verificamos que a tabela PARTSUPP não possuia um indice separado para o campo PS_SUPPKEY com isso foi criado o seguinte índice:

create index idx_partsupp_suppkey on PARTSUPP(ps_suppkey);

Com isso conseguimos diminuir tanto o QUERY COST quanto o tempo da consulta

• Execution Plan sem índice

• Execution Plan com índice criado

Tempo sem índice: De 2,4s a 3,1s

Tempo com índice: 0,6s

Mais uma vez a tabela ORDERS que não possui nenhum indice criado está sendo usado em uma condição de junção com isso foi criado o seguinte índice:

create index idx_order_orderkey on ORDERS(o_orderkey);

Ele foi suficiente para diminuir bastante o tempo da consulta e o QUERY COST

• Execution Plan sem índice

• Execution Plan com índice criado

Tempo sem índice: De 11,5 a 15s

Tempo com índice: 3,8s

Esta consulta também deu TIMEOUT A razão disso foi que mais uma vez a tabela ORDERS foi usada numa junção com isso foi criado o seguinte índice:

create index idx_order_custkey on ORDERS(o_custkey);

Apenas isso foi suficiente para fazer a consulta rodar

• Explain sem índice

• Execution Plan com índice criado

Tempo sem índice: Deu Timeout (mais de 60s)

Tempo com índice: 14,4s

Verificamos que poderíamos adicionar um índice para que o SGBD deixasse de fazer um FULL SCAN na tabela LINEITEM Com isso criamos o seguinte índice:

create index idx_lineitem_conditions on LINEITEM(l_shipdate, l_partkey);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 5,6s

Tempo com índice: 1,2s

Da mesma forma que a consulta 14, o objetivo aqui foi criar um índice que fosse capaz de trocar o FULL SCAN por RANGE SCAN Desta forma, criamos o seguinte índice:

create index idx_lineitem_shipdate on LINEITEM(l_shipdate);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 6,4s

Tempo com índice: 5,8s

Verificamos que neste caso o uso de índice não ajudou muito. Os índices diminuiram um pouco o query cost A diferença de tempo entre as consultas foi insignificante. Os indices criados foram os seguintes:

create index idx_part_size on PART(p_size);
create index idx_part_brand on PART(p_brand);

Sendo o primeiro o mais relevante por possibilitar um Range Scan como mostrado no Execution Plan

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 0,6s

Tempo com índice: 0,6s

Verificamos que a maior parte do custo nesta consulta deve-se a tabela PART Com isso criamos os seguintes índices:

create index idx_part_container on PART(p_container);
create index idx_part_brand on PART(p_brand);
create index idx_lineitem_partkey on LINEITEM(l_partkey);

O custo diminuiu bastante com a criação dos índices para a tabela PART. No entanto, o índice criado para a tabela LINEITEM não teve muito impacto, mas conseguiu diminuir minimamente o custo.

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 2,2s

Tempo com índice: 1,3s

Neste caso o uso de índice não ajudou muito. O tempo teve uma pequena variação, mas olhando para o EXECUTION PLAN Vemos que não houve diferença no QUERY COST O SGBD apenas escolheu usar o índice criado:

create index idx_lineitem_conditions on LINEITEM(l_orderkey, l_quantity);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 4,7s

Tempo com índice: 3,8s

Neste caso o objetivo foi tentar remover o FULL SCAN que estava sendo feito Com isso adicionamos o seguinte índice:

create index idx_part_conditions on PART(p_container, p_brand, p_size, p_partkey);

O tempo de execução não mudou muito, pois já era pouco antes da criação do índice No entanto, após a criação o SGBD conseguiu fazer um RANGE SCAN

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 0,3s

Tempo com índice: 0,2s

Verificamos o SGBD estava fazendo um FULL SCAN na tabela PART Com isso decidimos criar o seguinte índice:

create index idx_part_name on PART(p_name);

Após a criação do índice não houve mudança significativa no tempo da consulta, mas o QUERY COST diminuiu bastante

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 1,2s

Tempo com índice: 1,1s

create index idx_nation_name on NATION(n_name);

• Execution plain sem índice

• Execution Plan com índice criado

Tempo sem índice: 24,8s

Tempo com índice: 23,7s

Mais uma consulta que deu TIMEOUT A razão disso está no fato da tabela ORDERS não possuir nenhum índice

create index idx_order_custkey on ORDERS(o_custkey);
create index idx_customer_join on CUSTOMER(c_acctbal, c_phone);

• Explain sem índice

• Execution Plan com índice criado

Tempo sem índice: Deu Timeout (mais de 60s)

Tempo com índice: 0,26s