Pessoal, talvez a query de exemplo da mensagem anterior, nao foi um bom exemplo, pois utiliza somente 1 tabela. Mas tenho muitas outras queries, que envolvem muitas tabelas, com 3 tabelas realmente grandes: lineitem, Orders e partsupp. Da para ver que os predicados sao bem restritivos, e segundo regras basicas de tuning, se voce tem predicados restritivos (retorno entre 5 -10%) ai compensaria utilizar indices.
Bom o que acham, olhando a primeira query, aquele select interno " Select min(ps_supplycost)" veja que o select e' somente em 1 campo, e o FROM seria em 4 tabelas, neste caso um indice para pegar o valor minimo, seria uma boa aposta, o que acham? E na query 2, o campo l_extendedprice e l_discount, sera que um indice para calculo do em cada ou multiplo ali, traria beneficio, pensando que o predicado (where) seria bem restritivo? Essas queries sao de um benchmark que estou usando (http://www.tpc.org/tpch). ---------------------------------- select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment from part, supplier, partsupp, nation, region where p_partkey = ps_partkey and s_suppkey = ps_suppkey and p_size = 25 and p_type like '%STEEL' and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = 'EUROPE' and ps_supplycost = ( select min(ps_supplycost) from partsupp, supplier, nation, region where p_partkey = ps_partkey and s_suppkey = ps_suppkey and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = 'EUROPE' ) order by s_acctbal desc, n_name, s_name, p_partkey ----------------------------------------- select n_name, sum(l_extendedprice * (1 - l_discount)) as revenue from customer, orders, lineitem, supplier, nation, region where c_custkey = o_custkey and l_orderkey = o_orderkey and l_suppkey = s_suppkey and c_nationkey = s_nationkey and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = 'AMERICA' and o_orderdate >= date '1995-01-01' and o_orderdate < date '1995-01-01' + interval '1' year group by n_name order by revenue desc ------------------------------------------------ []`s Neto 2017-04-23 15:05 GMT-03:00 Neto pr <[email protected]>: > Pessoal, > > Tenho várias consultas como exemplo abaixo, e vou precisar executar em > bases com 100gb a 500gb do postgreSQL, brevemente. > > ------------------------------------------------------------------------ > select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, > sum(l_extendedprice) as sum_base_price, > sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, > sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, > avg(l_quantity) as avg_qty, > avg(l_extendedprice) as avg_price, > avg(l_discount) as avg_disc, > count(*) as count_order > from lineitem > where > l_shipdate <= date '2005-12-01' - interval '117' day > group by > l_returnflag, > l_linestatus > order by > l_returnflag, > l_linestatus; > -------------------------------------------------------------------------- > Vários autores (cito 3 exemplos abaixo) falam que uma coluna boa > candidata a índice deve: > - aparecer na clausula WHERE. > - aparecer em clausulas de GROUP BY ou ORDER BY > - etc... > > Mas pergunto, e as colunas que aparecem ANTES do WHERE, ou seja no > SELECT como as colunas com funções SUM, AVG e COUNT, como acima. > Pelo que entendi, um índice ajuda a encontar as linhas da tabela mais > rapidas, e com as linhas encontradas, nao precisaria de um indice para > fazer SUM, AVG, ou COUNT, seria isso a justificativa para os autores > não sugerirem criar índices para essas colunas com SUM, AVG e COUNT ? > e no caso de muitos dados para fazer o SUM, etc? > > Mas então porque para o Group By e Order by é sugerido a criação de > índices, pois na verdade eles fazer de forma similar o que faz o SUM, > AVG e COUNT, ou seja eles somente manipulam (ordenação/agrupamento) os > dados e não ajudam a encontrar os mesmo no discos. > > Na ref. 3 tem a seguinte afirmação: " Não indexe colunas que aparecem > em Cláusulas WHERE com funções ou operadores. > Uma cláusula WHERE que usa uma função, diferente de MIN ou MAX ou um > operador com uma chave indexada, não é disponibilizado o caminho de > acesso utilizando o índice, exceto com índices baseados em função." > > No entanto ele não fala nada de funcoes ANTES do WHERE. A minha > questão é compensa criar índices para colunas, se baseando nas colunas > que aparecem apos o SELECT? > > Obs. Eu sei que criar índices demasiadamente causa gargalos em > atualizações, mas meu ambiente, é mais orientado a consultas com > poucas atualizações. > > 1- http://www.cs.toronto.edu/~alan/papers/icde00.pdf (pag 1) > 2- Silberchatz, K et. al. Sistemas de banco de dados, Campus, 2006. > 3- https://docs.oracle.com/cd/E18283_01/server.112/e16638.pdf (Pag. 371) _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
