William Leite Araújo wrote: > > Esquecí de mencionar. A conversão inicial era de tabelas em DBF (clipper).
Você está voltando atras e dizendo então que o erro não é do PostGreSql e sim do DBF?? > Várias consultas sucessivas usando campo com o tipo "NUMERIC" e > nenhuma mágica ou magia negra ou qualquer outro modo obscuro da "força". > Apenas falta de atenção e pressa na execução de uma tarefa que me tomou > mais de um mês! Como eu disse, a limitação é de qualquer coisa menos do PostGreSQl, como voce está afirmando, a limitação foi sua que no momento não pensou na forma correta de fazer. O tempo desta rotina não foram 20h?? agora é um mês?? > Minha intenção é assustar mesmo. Fiquei pasmo quando isso aconteceu > e, caso tivesse tomado mais cuidado, certamente não teria perdido tanto > tempo acertando os procedimentos (óbvio que os testes da migração eram > feitos em uma base pequena, mas mesmo nelas, ao invés de receber o erro > em 30 segundos o mesmo demorava mais de 3 minutos...) Amigo, assuste de outra forma então, diga algo do tipo: "se você estiver cansado, com pressa, ou fazer POG a rotina vai ficar uma mer**, mas o PostGreSql "NÃO TEM PROBLEMAS EM TRATAR CAMPOS DO TIPO NUMERIC". > Não há nada de especial. Apenas consultas sucessivas a tabelas cuja > "constante" de comparação (no caso os valores [NEW].[coluna] que eram do > tipo NUMERIC. Calma la, de onde vem este [NEW]?? Estamos falando de trigger?? Você somente está deixando mais claro que a forma de fazer o processo foi errada e que tem sérios problemas de modelagem. > Infelizmente não posso divulgar, mas posso mostrar um exemplo numa > base qualquer. > > #select count(1) from xmls_logs; > count > ------- > 6159 > (1 registro) > > #select 1 from xmls_logs where xml_id = '534'::numeric; > ?column? > ---------- > 1 > (1 registro) > > *Tempo: 35,081 ms* > > # select 1 from xmls_logs where xml_id = '534'; > ?column? > ---------- > 1 > (1 registro) > > *Tempo: 1,456 ms* > > Isso numa tabela de 6156 registros... Cara, cade a estrutura da tabela xmls_logs?? A diferença de velocidade que você indica é porque as páginas de dados da tabela subiram para o cache na primeira consulta. Nada tem haver com os tipos de dados. Se logo em seguida à sua terceira consulta você executasse a segunda novamente os tempos seriam similares. -- Shander Lyrio _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral