2013/12/6 Matheus Saraiva <[email protected]> > Em 06-12-2013 17:19, Flavio Henrique Araque Gurgel escreveu: > > Por favor, pare com suas respostas em cima das outras. Responda abaixo ou >> comentando como outros colegas fazem. >> >> Valeu pela explicação, bem nos detalhes mesmo. >> >> Opa Xará, fico feliz em ajudar.
> Só que agora fiquei >>> indeciso depois da resposta do Cícero. Se eu fizer o indice com os três >>> campos index(A, B, C), também funcionaria? Ele seria usados em consultas >>> A and B, A and C, C and B, somente C e somente B? As regras seriam as >>> mesmas que você explicou? >>> >> >> Estratégia de índices vai muito além disso. >> Se você tem consultas que vão utilizar apenas um dos campos, entre outras >> consultas, às vezes vale a pena fazer índices separados, pois você terá >> índices menores para consultas específicas. >> >> Atravessar um índice para leitura custa caro: por se tratar de acesso >> randômico de disco, um índice é viável em determinadas situações. >> >> Faça você a análise: liste suas consultas. Crie os índices. Faça EXPLAIN >> ANALYZE das consultas sobre dados reais. Assim, você terá certeza de como >> seus índices serão utilizados, no seu caso específico. >> >> Às vezes, a estratégia de índices precisa de ajustes após ter sido >> colocada em produção. >> >> No seu caso, por exemplo, pode ser interessante até mesmo ter um índice >> cobrindo as três colunas, e mais um índice cobrindo uma coluna sozinha >> (sim, uma mesma coluna indexada em dois índices diferentes), e isso pode >> ser interessante para determinadas consultas. >> >> Os cuidados com índices em excesso são simples de entender: mais índices, >> maior carga na hora de escrever dados no banco e maior espaço em disco >> ocupado. >> >> []s >> >> Flavio Gurgel >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > Terei todas essas consultas que relatei (A and B, A and C, C and B, > somente C e somente B) > > Baseado do que vc afirmou, qual seria a prática adequada, colocar o banco > em produção sem índices, e cria-los depois de alguns dias baseado em uma > análise de uso? > > Opa. Primeiramente parabéns, parece que aprendeu a arte do bottom-post, e deixarás a galera aqui mais feliz (principalmente o Gurgel, =P ). Bom, a resposta para sua pergunta é que não há uma reposta certeira. ^^ Se você vai ter essas consultas que citou, os índices "perfeitos" (mas não ideias, aguarde) para as mesmas seria: (A,B), (A,C), (C,B), (C) e (B). Mas veja que são 5 índices para 5 consultas diferentes. Muitos índices ajudam mais consultas, mas deixam atualizações mais lentas. E, poderia ser que algumas consultas iriam bem sem índices tão perfeitos para as mesmas. Logo, o ideal (na minha opinião, principalmente por você não ter tanta experiência nessa área) é testar índices simples: (A), (B) e (C). Talvez até possa casar alguns (deixando sempre os três campos no início de pelo menos um), como (A, B), (C, B) e (B). Daí, para as consultas "somente C" e "somente B", o PostgreSQL utilizaria estes perfeitamente. Já para as consultas "A and B", "A and C" e "C and B" ele também usuária (podendo fazer os bitmaps e bitmapAND, como expliquei antes). O que você tem que verificar então é se essa operação é realmente suficiente (a performance é o esperado) ou se um índice que "casasse" perfeitamente seria "muito" melhor. Daí, para verificar isso, você pega sua consulta e faz: EXPLAIN (ANALYZE, VERBOSE, BUFFERS) SELECT ....; -- execute ao menos 5 vezes para eliminar efeito de cache Verifica quais índices ele está usando. Crie aqueles que casam "perfeitamente" e execute novamente a consulta, compare o valor e veja se é melhor ou pior. Fazendo isso constantemente você vai adquirindo experiência, chega uma hora que só olhando o resultado do comando acima você já sabe se precisa ou não de outro índice, precisará cada vez menos do "cria um índice e vê se ajuda". Para te ajudar a ler o resultado dessa consulta, você pode usar o explain.depesz.com [1]. Se quiser pode até postar o link do resultado aqui e nós te ajudamos na análise. [1] http://explain.depesz.com/ Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
