Olá pessoal, eu achu que essa frase responde minha duvida! "Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos os casos onde há a necessidade de mais de 5 índices por tabela. "
não é mesmo! 2009/10/2 Charly Frankl <[email protected]> > Senhores, boa noite... > > Vou entrar na conversa também. > > Com relação a índices, sempre é um assunto polêmico, mas muito > interessante, e de extrema importância no nosso trabalho. > Bem, não conheço a aplicação em questão, logo o que eu falar aqui será com > base em conceitos e boas práticas relacionadas a aplicação dos mesmos. > Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, > uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos > os casos onde há a necessidade de mais de 5 índices por tabela. Entendam são > "raros", e não "impossíveis". Existem problemas e situações onde isso não se > aplique, mas lembrem-se, apenas um dos tantos índices será utilizado na > pesquisa. Outro ponto importante, é o índice utilizado... Qual algorítmo? > Quais os tipos envolvidos? > > Com relação a atualização, assim como em uma pesquisa, o uso de índice não > é simplório, tendo em vista que o SGBD pode fazer uso de um índice mesmo que > o índice não esteja envolvido diretamente na pesquisa (vejam que aumentamos > a complexidade aqui!) a atualização também não é simplória ao ponto de o > SGBD não "tocar" em um índice que não esteja envolvido na atualização da > entidade. Isso digo não apenas do PostgreSQL, mas do Oracle e DB2. As > implicações em termos muitos índices são muitas, e o custo de manutenção dos > mesmos devem ser levados em conta sim! > > Compreendo que aplicações de BI/DW se utilizam de uma técnica não > "ortodoxa" de modelagem, e que muitos conceitos referentes a normalização > são de certa forma "desprezados" em virtude de aumento na performance das > pesquisas, até porque não são bases OLTP com auto indice transacional. Logo > são aplicações não ortodoxas, que se dão ao direito de não terem > preocupações com custos e perdas no momento de atualização. Ainda assim, a > grande quantidade de índices não implica diretamente na melhoria da > performance das buscas, pois se os mesmos não forem bem planejados, podemos > ter índices nunca utilizados ocupando espaço desnecessário, e infringindo > uma perda também desnecessária inclusive no momento da pesquisa, pois o > otimizador pode, e eventualmente vai, perder tempo em desconsiderar aquele > índice como um candidato não eletivo. Lembrem-se, ainda que não utilizado, > ele faz parte do dicionário de dados, o qual é utilizado pelo otimizador no > momento de decidir qual índice eleger para pesquisa. > > Bem, finalizando (ainda que querendo falar mais... :-D), podemos perceber > que o tema é complexo, e não simplista... Existem muitos pontos e variáveis > a serem observadas... Todavia, a minha recomendação é, não extrapolem na > utilização de índices, vão infringir uma carga muito grande de trabalho ao > SGBD, e aqui indifere o SGBD. Comecem sempre com implementações > conservadoras, e a medida que o tempo passar e existirem informações, > apliquem as melhorias de tunning e performance necessária. Primem por manter > saudável o SGBD, e o excesso de índice pode comprometer a saúde do mesmo! > > Ah, e antes que me esqueça... Senhores, acalmem-se, estamos aqui para nos > ajudar. Não deixemos que a sexta-feira e o cansaço leve para o lado pessoal > nossos debates. Eles são muito construtivos, ainda que não concordemos com > todos os pontos de vista apresentados. > > Um grande abraço a todos, e um excelente final de semana! > > > > -- > Charly Frankl > http://javadevilopers.blogspot.com/ > [email protected] > Linux user #391083 > > > > 2009/10/2 Euler Taveira de Oliveira <[email protected]> > > Mozart Hasse escreveu: >> > Como assim "pelo menos 1+32+1"?! Tem certeza que o Postgres ainda é tão >> > simplório?! O Oracle e SQL Server por exemplo só tocam num índice se a >> > atualização se referir a campos pertencentes a ele. >> O PostgreSQL também (vide HOT) mas como *não* sei a que versão se refere >> preferi afirmar algo conservador... >> >> > Quanto a inserções (em que pelo menos todos os índices *não >> condicionais* >> > são atualizados), obviamente elas serão relativamente mais lentas com >> > índices (se você medir com precisão a média em milissegundos), mas isso >> > nem de longe pode ser considerado um problema conceitual >> Conceito *não*, mas de organização física. >> >> Você *não* mostrou essa tal tabela, os índices dela e, o mais importante, >> as >> estatísticas de uso desses índices. Posso estar errado (pois não vi a sua >> estrutura) mas já presenciei vários cenários em que combinei alguns >> índices e >> diminuí consideravelmente o número deles sem prejudicar as consultas que >> os >> utilizam. Assim, eu consegui aumentar o número de DML/s consideravelmente. >> >> > Se eu quisesse gravar mais rápido do que >> > consultar, meteria os dados num arquivo TXT, não num banco de dados. >> Como tu farias integridade referencial em um TXT? Não menospreze anos de >> pesquisa em teoria de SGBDs. >> >> > Já que você acha que conhece jeitos menos "errados" de modelar uma >> tabela >> > que você nem sabe para que serve, nem quantos registros tem, nem a que >> > consultas é submetida, manda lá sua sugestão sobre o que faço para >> tornar >> > mais rápidas as gravações sem tornar imprestáveis as consultas à minha >> > "tabelinha" de 89 campos, 20 chaves estrangeiras, 44 índices e não menos >> do >> > que 100000 registros. >> > >> Ugh? Como vou supor algo que _não_ vi? >> >> >> -- >> Euler Taveira de Oliveira >> http://www.timbira.com/ >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: [email protected] email: [email protected]
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
