Wagner, > Minhas dúvidas são: > - essa prática de inserir todas essas entradas na hora do cadastro é > errado ou não tem problema?
Provavelmente há maneiras melhores. É, no mínimo, uma alternativa não recomendada e só justificável em raríssimos casos. > - a demora é porque o servidor está muito lento (ou seja, esses 12000 > inserts deveriam ser mais rapidos)?? 12000 registros em *dois* intermináveis minutos?! Eu acho que está horrivelmente lento até para uma estaçãozinha Windows com 512K de RAM e um mísero disco IDE, transformada em servidor de e-mail e Postgres. Tua tabela está entupida de índices e chaves estrangeiras (mais de 10?) ?! Mesmo que esteja, tenho lá minhas dúvidas que leve isso tudo. Veja se consegue fazer os 12000 inserts num comando só (INSERT INTO SELECT), caso não esteja fazendo isso. Você pode também tentar dividir essa tabela em outras menores (com menos campos), para que o insert seja sobre uma tabela com registros e índices menores. > - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se > fui muito claro no problema, mas uma coisa interessante de citar é que > essas entradas entre todos os clientes e entre os clientes e todos os > filmes é importante pois o site calcula notas sugeridas para cada > usuário, dependendo dos votos deles e da semelhança dos votos com > outros usuários. Não sei se isso justifica inserir 12000 registros, mas enquanto não tiver oção melhor... Outra coisa que sempre dá para fazer é deixar essa inserção como um processo em segundo plano, em outra transação independente. Você cadastra o cara numa transação minúscula (INSERT na tabela de usuários e era isso) e deixa o registro dele *marcado* como *pendente* (sim, isso pode dar trabalho para tratar nas outras telas do sistema, mas você quer uma alternativa com desempenho *viável*, não quer?!). Um outro processo (que você vai precisar implementar) roda de tempos em tempos vendo quem está pendente e lasca o INSERT nos registros que encontrar, alterando a situação quando for bem sucedido. Enquanto este segundo passo não for feito, o cara fica cadastrado, mas ainda não acessa toda a funcionalidade do site (porém já tem login e senha garantidos) nem entra na conta dessa tabela de 12000 registros por cabeça, mantendo sua transação de cadastro bem leve. Bom, vai um bom aviso: apelar para processos em segundo plano é um caso *_*_e_x_t_r_e_m_o_*_* (leia-se esta palavra com fonte grande, negrito, itálico e sublinhado) que só deveria ser aplicado se não houver outra maneira de guardar os dados que você precisa nessa tabela todos-com-todos. Acho muito provável que você possa transformar essa tabela em duas ou três tabelas menores com uma aparente redundância e índices bem escolhidos, e que essas tabelas possam te dar o desempenho necessário ou mesmo superior com uma fração do número de registros que você tem hoje. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
