Em 18/10/2013 17:43, "Ivan Emanuel de Moura Leite" <[email protected]> escreveu: > > Olá Anselmo, > Tente colocar o novo schema como padrão para novas criações como set search_path ="seu_schema"; e use =# \i arquivo.dump \o arquivo.saida para gravar as mensagens do restore e ver o que esta consumindo tanto recurso. Veja também os índices de coluna, talvez o restore esta demorando na recriação e reordenação dos mesmo s. Ao fazer o dump verifique os flags na documentação do Pgsql, eles podem ajudar no desempenho do restore. > > Em 18/10/2013 15:12, "Anselmo Silva" <[email protected]> escreveu: >> >> >>> Olá Anselmo M. Silva, >>> O método usado para transferir as tabelas por você (pg_dump,pg_restore) é o mais eficiente em todos os sentidos, mesmo entre bases contidas no mesmo "servidor". Tenho certeza que a comunidade irá indicar o mesmo para você. >>> >> blz... a dúvida para melhora seria para a transferência de dados num cenário como este ou de usar um método mais ortodoxo para fazer o restore no schema (que funcione). >> >> Falando nisso, executei o script modificado e houve uma perda de desempenho ao longo dos inserts. >> >> -- >> Anselmo M. Silva >> >> _______________________________________________ >> 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 > Não estou tendo problemas com performance no restore... Este foi feito com sucesso, como dito... Apenas no momento do insert que antes seria feito com o dblink, perde performance com o passar do tempo. Vou ver se dou uma tunada no PostgreSQL para ver se melhora
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
