Olá Flávio,
Essa é a chave da tabela:
pk_tb_matricula PRIMARY KEY(matr , cursocod , gradecod , disccodof ,
periodo , ano );
Esses são os 2 índices que fizeram diferença na execução da consulta do
programa:
CREATE INDEX turma_teo
ON tb_matricula
USING btree
(turmateo COLLATE pg_catalog."default" , ano , periodo );
CREATE INDEX turmapra_idx
ON tb_matricula
USING btree
(turmapra COLLATE pg_catalog."default" , ano , periodo );
Esta é a consulta complicada:
O problema é que o programa faz um FOR nesta consulta, pois é um count de
cada turma.
explain analyze SELECT COUNT(*)
FROM TB_MATRICULA
WHERE DISCCODOF= 'ADM082' AND
LOCALCOD = 'C01' AND
((REGIME = 'A' AND ANO = 2012) OR
(REGIME !='A' AND ANO = 2012 AND PERIODO = 1)) AND
(TURMATEO = 'X') OR
('TURMAPRA = 'Y'));
Esse foi o resultado do Explain:
"Aggregate (cost=4835.89..4835.90 rows=1 width=0) (actual
time=39.486..39.486 rows=1 loops=1)"
" -> Index Scan using pk_tb_matricula on tb_matricula
(cost=0.00..4835.02 rows=351 width=0) (actual time=0.190..39.231 rows=1520
loops=1)"
" Index Cond: (((disccodof)::text = 'ADM082'::text) AND (ano =
2012))"
" Filter: ((localcod = 'C01'::bpchar) AND (((turmateo)::text =
'1'::text) OR ((turmapra)::text = ''::text)) AND ((regime = 'A'::bpchar) OR
((regime <> 'A'::bpchar) AND (periodo = 1))))"
"Total runtime: 39.591 ms"
No aguardo!!
Em 8 de fevereiro de 2013 13:58, Flavio Henrique Araque Gurgel <
[email protected]> escreveu:
> > Olá pessoal,
> >
> > Temos uma tabela que em um determinado tempo ela é muito consultada e ao
> > mesmo tempo sofre muitos inserts e updates.
> >
> > Acontece que a consulta é bem complexa e está ficando cada vez mais
> lenta com
> > o aumento do número de dados.
>
> Você poderia nos passar um EXPLAIN ANALYZE da consulta que está ficando
> lenta?
>
> > Decidimos então testar a criação de uns índices com os principais campos
> nas
> > cláusulas WHERE das consultas mais lentas.
> >
> > A consulta ficou bem mais rápida, mas estamos receosos se estes índices
> irão
> > deixar mais lenta a inserção e update de dados
> > pois esses comandos teriam então que inserir no índice também.
>
> Sim, os INSERT e UPDATE vão ficar mais lentos.
> Você terá de balancear o custo x benefício dos índices.
>
> Pra saber se os índices estão sendo realmente eficientes para o SELECT,
> envie-nos o EXPLAIN ANALYZE que solicitei acima.
>
>
>
> >
> >
> > Obs.:
> >
> > Criamos 2 índices compostos btree.
> > (campo1, campo2, campo3)
> > (campo4, campo2, campo3)
> >
> > campo2 e campo3 fazem parte da chave da tabela que possui 5 campos chave.
> >
> > Detalhe: temos 2 consultas muito pesadas que usam no where campo1,
> campo2 e
> > campo3 e campo4, campo2 e campo3 respectivamente.
>
> Provavelmente o índice é interessante, mas só com o EXPLAIN ANALYZE dá pra
> ajudar.
>
> []s
>
> __________________________________
> Flavio Henrique A. Gurgel
> Líder de Projetos Especiais
> Consultoria, Projetos & Treinamentos 4LINUX
> Tel1: +55-11.2125-4747 ou 2125-4748
> www.4linux.com.br
> email: [email protected]
> ______________________________
> FREE SOFTWARE SOLUTIONS
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
--
*Wellington Openheimer Ribeiro*
Analista de Tecnologia da Informação
*UNIFEI - Universidade Federal de Itajubá*
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
