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
