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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
