Euler, > Mozart Hasse escreveu: > >> Euler escreveu: > >> Você está querendo ter mais do que 32 índices em uma tabela? Há algo > > errado > >> com o seu modelo de dados, não? > > > > Ué, errado por quê?! > > > Simplesmente porque atualizar um registro implica em atualizar pelo menos 1 + > 32 + 1 arquivos. Isso é uma operação muito custosa senão inviável em alguns > cenários.
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. 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, pois dados são inseridos para serem consultados. Se eu quisesse gravar mais rápido do que consultar, meteria os dados num arquivo TXT, não num banco de dados. 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. Isso, claro, se você achar que tem argumentos para discordar do que eu disse anteriormente: > Esquartejar essa tabela em duas ou mais considerando que eu quase sempre > uso todos os 89 campos juntos soa não só como um contra-senso como > prejudica muito qualquer esperança de desempenho. Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
