Mozard, - Verifiquei os Índices, so tenho idx para PK e FK mais nada. - Criei novas funções para testar as funções auxiliares (Cod. barras por ex.)
- As tabelas estão vazias , mesmo assim verifiquei as config. do Pg. Por ultimo quando já ia partir para reescrever a função, reduzi os NOTICE como vc havia falado. Cara funcionou!! O que não entendo é isso incluenciar para o insert ficar cada vez mais lento, eu faço em média 1.500.000 inserts cada vez que rodo a função. Agora manteve a média por seg de inserts. Vlw, Márcio Bernardino 2009/7/27 Mozart Hasse <mozart.ha...@usa.net> > Olá Márcio, > > Os motivos que me ocorrem são: > > 1. EXCESSO de índices: tornam a gravação mais lenta, apesar de não ser meu > palpite, pois você precisaria ter uns 20 índices muito mal escolhidos nessa > tabela para isso começar a ficar aparente. Para tirar a dúvida, descarte um > ou dois índices cheios de campos e veja se faz uma grande diferença. Se não > fizer, nem esquente e recoloque-os; > > 2. Excesso de raise NOTICES: com vários registros, o número de linhas > geradas no resultado fica grande muito rápido, talvez esse tráfego possa > atrapalhar o desempenho. Tire os RAISE NOTICE ou faça um a cada 1000 > registros para ver se há diferença. Se não melhorar, deixe-os lá mesmo; > > 3. FALTA de índices: vejo que há várias tabelas com FK no nome e que > aparentemente você está incluindo registros na tabela "pai" e depois nas > "filhas". Certifique-se de que todas as suas tabelas têm índices para PKs e > FKs e que esses ORDER BY são de fato esseciais (caso sejam tente por > índices > para eles); > > 4. Você verificou se essas funções de geram código de barras têm desempenho > constante? Suponho que sim, mas, sem o fonte é necessário verificar se elas > não andam gravando coisas em lugares inesperados ou se não têm alguma falha > de programação (memory leak) e isso causa a perda gradativa de desempenho; > > 4. Memória menor do que as tabelas ou aproveitamento inadequado do buffer: > Se essas tabelas forem enormes, vai compensar bastante preencher uma de > cada > vez. Troque esse monte de loops um dentro do outro por um que só preencha a > tb_extracoes_bilhetes, depois outro loop que preencha só a > tb_extracoes_bilhetes_fracoes e depois outro que só de inserts na > tb_extracoes_bilhetes_numeros. Via de regra vários loops seguidos (mesmo > com > reprocessamento dos mesmos dados) são muito melhores que um loop grandão > feito o seu; > > 5. Transação grande demais: se usar valores muito grandes para > arg_bilhetes_a_gerar, o servidor vai sofrer para fazer toda essa > parafernália numa só transação, especialmente se chegar perto do limite do > tamanho de transação do postgres sem ultrapassá-lo (não é difícil chegar > perto ou tropeçar nesse limite infame com uma tabela grande). Usar números > pequenos demais é um desastre, porém caso não tenha procurado vale a pena > pesquisar valores maiores ou menores que os que você andou usando. > > Quando resolver, ficarei curioso em saber o que foi. > > Atenciosamente, > > Mozart Hasse > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
