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
