William Leite Araújo escreveu: > 2008/7/30 Shander Lyrio <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > > (...) > Eu acredito que numeric deva ser utilizando sempre que se > precisar de > um campo do tipo numeric. Nunca vi nem ouvi esta história de quantidade > de registros. Se você precisa fazer conversão é provavel que sua > modelagem inicial tenha sido errada e nada tem haver com o tipo numeric > em si. > > > Esquecí de mencionar. A conversão inicial era de tabelas em DBF (clipper). > > > (...) > Amigo, mágica não existe. Certamente existe outra coisa erra > nos tais > "procedimentos" e não é o uso de numeric que causou este problema. Eu > uso extensivamente peso, cubagem e preços com numeric em tabelas com > muito mais registros do que o que você cita e nunca vi nada de anormal. > > > 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! > > > > Vamos tomar cuidado com este tipo de afirmação categórica na > lista sem > nenhum embasamento científico para evitar que colegas que cairam no > PostGreSql de paraquedas e ainda estão iniciando seus estudos achem que > isto é uma regra. > > > 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...) > > > > É muito mais fácil o seu "procedimento específico" ter sido > executado > de forma pouco performática por qualquer outra limitação de ambiente do > que o PostGreSql manter um tipo de dados que não deveria ser usado pois > apresenta performance 600 vezes menor que outro. > > > 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. > > > > Dados científicos, paupáveis e replicáveis para embasar esta > recomendação?? > > > 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... >
William: Só para fins de esclarecimento: Você pode rodar as duas consultas acima mas em ordem invertida? Isso é: Primeiro: select 1 from xmls_logs where xml_id = '534'; e logo depois: select 1 from xmls_logs where xml_id = '534'::numeric; e reportar os tempos obtidos? Osvaldo _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
