Discussion:
Quando usar? REAL, DOUBLE PRECISION e NUMERIC
Glauber Almeida
2008-07-29 13:02:32 UTC
Permalink
Pessoal,

estou fazendo um projeto de banco de dados para um ERP feito em COBOL
e que já roda a quase 15 anos trabalhando com arquivos ISAM.
No instante inicial defini na modelagem todos os campos numéricos,
reais, percentuais e quantidades como REAL, para depois avaliar caso a caso
o tipo correto a ser usado, por exemplo, passar os percentuais para
numeric(4,2). Agora estou com uma dúvida, será que vale a pena efetuar essa
mudança? Se eu deixar tudo como REAL, vou perder em questão de armazenamento
e recuperação?

Abraços.
Glauber de Almeida
--
View this message in context: http://www.nabble.com/Quando-usar---REAL%2C-DOUBLE-PRECISION-e-NUMERIC-tp18711631p18711631.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
Ribamar Sousa
2008-07-29 13:56:53 UTC
Permalink
Post by Glauber Almeida
Pessoal,
estou fazendo um projeto de banco de dados para um ERP feito em COBOL
e que já roda a quase 15 anos trabalhando com arquivos ISAM.
No instante inicial defini na modelagem todos os campos numéricos,
reais, percentuais e quantidades como REAL, para depois avaliar caso a caso
o tipo correto a ser usado, por exemplo, passar os percentuais para
numeric(4,2). Agora estou com uma dúvida, será que vale a pena efetuar essa
mudança? Se eu deixar tudo como REAL, vou perder em questão de armazenamento
e recuperação?
Glauber, o manual detalha com bastante detalhes os tipos de dados e seu uso.
Veja:
http://pgdocptbr.sourceforge.net/pg80/datatype.html
http://www.postgresql.org/docs/8.3/interactive/datatype.html
--
Ribamar FS - ***@ribafs.net
http://ribafs.net
William Leite Araújo
2008-07-30 11:24:41 UTC
Permalink
Posso dizer, por experiência própria, que o uso de numeric/decimal só é
indicado em casos onde a quantidade de registros é pequeno e/ou não é usado
em processamentos feito pelo banco de dados (qualquer fórmula e/ou
conversão).

No ano passado, num processo de migração, converti o tipo decimal(x,y)
para o mesmo tipo no postgres, e ao trabalhar com campos desse tipo em
procedimentos, a migração de uma simples tabela de menos de 500.000
registros durava mais de 20 horas. Ao converter esses campos para inteiro
(pois a parte decimal nem era usada), o tempo de processamento caiu para 2
minutos. Isso mesmo! Na verdade deve ser menos que 2 minutos... um absurdo,
mas um caso real.

Dessa forma, caso vá usar o valor que está sendo armazenado em algum
procedimento/view/fórmula, não recomento tipo decimal/numerico.
Post by Ribamar Sousa
Post by Glauber Almeida
Pessoal,
estou fazendo um projeto de banco de dados para um ERP feito em COBOL
e que já roda a quase 15 anos trabalhando com arquivos ISAM.
No instante inicial defini na modelagem todos os campos numéricos,
reais, percentuais e quantidades como REAL, para depois avaliar caso a caso
o tipo correto a ser usado, por exemplo, passar os percentuais para
numeric(4,2). Agora estou com uma dúvida, será que vale a pena efetuar
essa
mudança? Se eu deixar tudo como REAL, vou perder em questão de
armazenamento
e recuperação?
Glauber, o manual detalha com bastante detalhes os tipos de dados e seu uso.
http://pgdocptbr.sourceforge.net/pg80/datatype.html
http://www.postgresql.org/docs/8.3/interactive/datatype.html
--
http://ribafs.net
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
William Leite Araújo
Analista de Banco de Dados - QualiConsult
Ribamar Sousa
2008-07-30 11:48:39 UTC
Permalink
Posso dizer, por experiência própria, que o uso de numeric/decimal só
é indicado em casos onde a quantidade de registros é pequeno e/ou não é
usado em processamentos feito pelo banco de dados (qualquer fórmula e/ou
conversão).
No ano passado, num processo de migração, converti o tipo decimal(x,y)
para o mesmo tipo no postgres, e ao trabalhar com campos desse tipo em
procedimentos, a migração de uma simples tabela de menos de 500.000
registros durava mais de 20 horas. Ao converter esses campos para inteiro
(pois a parte decimal nem era usada), o tempo de processamento caiu para 2
minutos. Isso mesmo! Na verdade deve ser menos que 2 minutos... um absurdo,
mas um caso real.
Dessa forma, caso vá usar o valor que está sendo armazenado em algum
procedimento/view/fórmula, não recomento tipo decimal/numerico.
Cara, por isso que se está começando a valorizar mais a experiência do que
graduações, do que certificações.
Veja que somente a prática mostra uma informação como essa sua, William.
Isso não desvaloriza em nada a informação (acadêmica ou não), mas sim
valoriza a experiência.
A formação acadêmica tem seu valor, mas se ela vier acompanhada com a
experiência terá um maior valor.
Post by Ribamar Sousa
Post by Glauber Almeida
Pessoal,
estou fazendo um projeto de banco de dados para um ERP feito em COBOL
e que já roda a quase 15 anos trabalhando com arquivos ISAM.
No instante inicial defini na modelagem todos os campos numéricos,
reais, percentuais e quantidades como REAL, para depois avaliar caso a caso
o tipo correto a ser usado, por exemplo, passar os percentuais para
numeric(4,2). Agora estou com uma dúvida, será que vale a pena efetuar essa
mudança? Se eu deixar tudo como REAL, vou perder em questão de armazenamento
e recuperação?
Glauber, o manual detalha com bastante detalhes os tipos de dados e seu uso.
http://pgdocptbr.sourceforge.net/pg80/datatype.html
http://www.postgresql.org/docs/8.3/interactive/datatype.html
--
http://ribafs.net
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
William Leite Araújo
Analista de Banco de Dados - QualiConsult
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Ribamar FS - ***@ribafs.net
http://ribafs.net
Shander Lyrio
2008-07-30 17:39:22 UTC
Permalink
Posso dizer, por experiência própria, que o uso de numeric/decimal
só é indicado em casos onde a quantidade de registros é pequeno e/ou não
é usado em processamentos feito pelo banco de dados (qualquer fórmula
e/ou conversão).
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.
No ano passado, num processo de migração, converti o tipo
decimal(x,y) para o mesmo tipo no postgres, e ao trabalhar com campos
desse tipo em procedimentos, a migração de uma simples tabela de menos
de 500.000 registros durava mais de 20 horas. Ao converter esses campos
para inteiro (pois a parte decimal nem era usada), o tempo de
processamento caiu para 2 minutos. Isso mesmo! Na verdade deve ser menos
que 2 minutos... um absurdo, mas um caso real.
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.

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.

É 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.
Dessa forma, caso vá usar o valor que está sendo armazenado em
algum procedimento/view/fórmula, não recomento tipo decimal/numerico.
Dados científicos, paupáveis e replicáveis para embasar esta recomendação??

--
Shander Lyrio
Alisson Viegas | Acsiv Sistemas
2008-07-30 18:20:30 UTC
Permalink
Boa Shander!

-----Mensagem original-----
De: pgbr-geral-***@listas.postgresql.org.br
[mailto:pgbr-geral-***@listas.postgresql.org.br] Em nome de Shander
Lyrio
Enviada em: quarta-feira, 30 de julho de 2008 14:39
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
Posso dizer, por experiência própria, que o uso de numeric/decimal
só é indicado em casos onde a quantidade de registros é pequeno e/ou não
é usado em processamentos feito pelo banco de dados (qualquer fórmula
e/ou conversão).
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.
No ano passado, num processo de migração, converti o tipo
decimal(x,y) para o mesmo tipo no postgres, e ao trabalhar com campos
desse tipo em procedimentos, a migração de uma simples tabela de menos
de 500.000 registros durava mais de 20 horas. Ao converter esses campos
para inteiro (pois a parte decimal nem era usada), o tempo de
processamento caiu para 2 minutos. Isso mesmo! Na verdade deve ser menos
que 2 minutos... um absurdo, mas um caso real.
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.

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.

É 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.
Dessa forma, caso vá usar o valor que está sendo armazenado em
algum procedimento/view/fórmula, não recomento tipo decimal/numerico.
Dados científicos, paupáveis e replicáveis para embasar esta
recomendação??

--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
pgbr-***@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.5.7/1581 - Release Date: 30/07/2008
06:56
Celso
2008-07-30 23:02:22 UTC
Permalink
Nós também utilizamos Numeric em todos os campos inteiros (para limitar a
quantidade de dígitos que o usuário poderá informar) e decimais.

Também não temos nenhum problema de performance.

Não acredito que seja problema do Postgres tb.

Att,

Celso Lorenzetti
www.sysrs.com.br

----- Original Message -----
From: "Shander Lyrio" <***@yahoo.com.br>
To: "Comunidade PostgreSQL Brasileira" <pgbr-***@listas.postgresql.org.br>
Sent: Wednesday, July 30, 2008 2:39 PM
Subject: Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
Posso dizer, por experiência própria, que o uso de numeric/decimal
só é indicado em casos onde a quantidade de registros é pequeno e/ou não
é usado em processamentos feito pelo banco de dados (qualquer fórmula
e/ou conversão).
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.
No ano passado, num processo de migração, converti o tipo
decimal(x,y) para o mesmo tipo no postgres, e ao trabalhar com campos
desse tipo em procedimentos, a migração de uma simples tabela de menos
de 500.000 registros durava mais de 20 horas. Ao converter esses campos
para inteiro (pois a parte decimal nem era usada), o tempo de
processamento caiu para 2 minutos. Isso mesmo! Na verdade deve ser menos
que 2 minutos... um absurdo, mas um caso real.
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.

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.

É 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.
Dessa forma, caso vá usar o valor que está sendo armazenado em
algum procedimento/view/fórmula, não recomento tipo decimal/numerico.
Dados científicos, paupáveis e replicáveis para embasar esta recomendação??

--
Shander Lyrio
Osvaldo Kussama
2008-07-31 01:15:12 UTC
Permalink
Post by Celso
Nós também utilizamos Numeric em todos os campos inteiros (para limitar a
quantidade de dígitos que o usuário poderá informar) e decimais.
Também não temos nenhum problema de performance.
Não acredito que seja problema do Postgres tb.
Não há dúvida que as operações utilizando aritmética binária (int,
bigint, float, double) são mais rápidas que as que utilizam aritmética
decimal (decimal ou numeric). É uma questão de hardware.

Nem sempre é aconselhável utilizar aritmética binária em ponto
flutuante devido à precisão e arredondamento. Quando não se pode
conviver com esta aproximações devemos utilizar a aritmética decimal.
(isto vem desde a época do Cobol...)

Quanto à diferença de desempenho nunca ouvi falar de diferença tão
gritante quanto a relatada (600 vezes).

Quando devemos utilizar uma ou outra?
Se você pode conviver com as aproximações e eventuais pequenas
diferenças, como por exemplo cálculos científicos, então use float ou
double (é aquilo da matemática: um valor mais ou menos um desvio).
Se você necessita precisão, por exemplo com valores monetários nos
quais um centavo é motivo de encrenca com o contador, então utilize
numeric ou decimal.

Osvaldo
William Leite Araújo
2008-08-05 18:45:04 UTC
Permalink
Post by Shander Lyrio
(...)
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).
Post by Shander Lyrio
(...)
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!
Post by Shander Lyrio
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...)
Post by Shander Lyrio
É 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.
Post by Shander Lyrio
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 Leite Araújo
Analista de Banco de Dados - QualiConsult
Osvaldo Rosario Kussama
2008-08-05 19:43:58 UTC
Permalink
Post by Shander Lyrio
(...)
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
Shander Lyrio
2008-08-05 20:01:32 UTC
Permalink
Post by Osvaldo Rosario Kussama
Só para fins de esclarecimento: Você pode rodar as duas consultas
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?
Matou a questão do cache de páginas de forma muito mais elegante
Osvaldo, preciso aprender contigo.

--
Shander Lyrio
William Leite Araújo
2008-08-05 20:23:40 UTC
Permalink
Não é cache. É falta de tato ao explicar o problema.
Ao invés de criar o campo value como numeric, use integer. Em seguida,
faça o teste.

novo=# create table tablefoo2(anytext varchar(100), valor serial);;
NOTA: CREATE TABLE criará sequência implícita "tablefoo2_valor_seq" para
coluna serial "tablefoo2.valor"
CREATE TABLE
Tempo: 23,205 ms
novo=# insert into tablefoo2(anytext) select 'iteration
'||to_char(random()*100,'99D999') from generate_series(0,50000);
INSERT 0 50001
s
Tempo: 1,615 ms

select 1 from tablefoo2 where valor = 1;
?column?
----------
1
(1 registro)

*Tempo: 24,209 ms*
novo=# select 1 from tablefoo2 where valor = 1::numeric;
?column?
----------
1
(1 registro)

*Tempo: 55,790 ms*
Só para fins de esclarecimento: Você pode rodar as duas consultas
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?
Matou a questão do cache de páginas de forma muito mais elegante
Osvaldo, preciso aprender contigo.
--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
William Leite Araújo
Analista de Banco de Dados - QualiConsult
Evandro Ricardo Silvestre
2008-08-05 20:29:01 UTC
Permalink
Post by William Leite Araújo
novo=# select 1 from tablefoo2 where valor = 1::numeric;
Apenas me explique o porque está fazendo esse CAST? Qual o motivo de
fazer um cast de um Integer para Numeric para comparar com um campo
Integer??
Não está batendo muito em uma tecla que não deve ser feita?

Att

Evandro
Shander Lyrio
2008-08-05 20:34:47 UTC
Permalink
Não é cache. É falta de tato ao explicar o problema.
Ao invés de criar o campo value como numeric, use integer. Em
seguida, faça o teste.
Realmente não é cache, já expliquei o problema em e-mail anterior.

Abraço,

--
Shander Lyrio
Shander Lyrio
2008-08-05 20:49:43 UTC
Permalink
Post by Evandro Ricardo Silvestre
Post by William Leite Araújo
novo=# select 1 from tablefoo2 where valor = 1::numeric;
Apenas me explique o porque está fazendo esse CAST? Qual o motivo de
fazer um cast de um Integer para Numeric para comparar com um campo
Integer??
Não está batendo muito em uma tecla que não deve ser feita?
Evandro,

Isto quem fez foi eu, o amigo informou que existiam problemas de
performance no tipo numeric e eu fiz teste de todas as formas possíveis
e IMPOSSÍVEIS para provar que o PostGreSql não tem nenhum problema com
campos numeric. Inclusive fiz vários casts absurdos e o PostGreSql
respondeu bem até as consultas mais bizonhas.

Está acompanhando toda a thred??

Abraço,

--
Shander Lyrio
Shander Lyrio
2008-08-05 20:00:12 UTC
Permalink
Post by Shander Lyrio
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??
Post by Shander Lyrio
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??
Post by Shander Lyrio
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".
Post by Shander Lyrio
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.
Post by Shander Lyrio
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
William Leite Araújo
2008-08-06 11:10:49 UTC
Permalink
Finalizando a discussão.

Obrigado pela defesa ao Postgresql. Retiro TUDO que eu disse e caso
tenha causado desconforto ou mal-estar, minhas sinceras desculpas.

Eu quis somente enumerar um problema que me incomodou profundamente. Na
ocasião, a solução foi fazer um CAST para a constante, que tinha tipo
NUMERIC para INTEGER. Ao fazê-lo, o tempo caiu VERTIGINOSAMENTE.

Atenciosamente,
--
William Leite Araújo
Analista de Banco de Dados - QualiConsult
Ribamar Sousa
2008-08-06 11:37:47 UTC
Permalink
Finalizando a discussão.
Obrigado pela defesa ao Postgresql. Retiro TUDO que eu disse e caso
tenha causado desconforto ou mal-estar, minhas sinceras desculpas.
Eu quis somente enumerar um problema que me incomodou profundamente.
Na ocasião, a solução foi fazer um CAST para a constante, que tinha tipo
NUMERIC para INTEGER. Ao fazê-lo, o tempo caiu VERTIGINOSAMENTE.
Atenciosamente,
Aproveitando sua atitude Willian, gostaria de fazer um rápido comentário:
que em discussões comoe esta nós sempre nos lembremos que estamos discutindo
não para ter razão, mas para ampliar nossos conhecimentos.
Acredito que até o tom de voz precisa ser diferente. Somos muito ríspidos
algumas vezes: "Você está enganado". Poderia ser "Você tem certeza?".
Se o clima respirado aqui for mais ameno vamos nos sertir mais em casa e
nossa produtividade melhora.
--
Ribamar FS - ***@ribafs.net
http://ribafs.net
Paulo
2008-08-06 11:43:57 UTC
Permalink
Gostaria de saber ser voces conhecem algum ODBC Postgresql e NATURAL/ADABAS
----- Original Message -----
From: Ribamar Sousa
To: Comunidade PostgreSQL Brasileira
Sent: Wednesday, August 06, 2008 8:37 AM
Subject: Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC


2008/8/6 William Leite Araújo <***@grupoquali.com.br>

Finalizando a discussão.

Obrigado pela defesa ao Postgresql. Retiro TUDO que eu disse e caso tenha causado desconforto ou mal-estar, minhas sinceras desculpas.

Eu quis somente enumerar um problema que me incomodou profundamente. Na ocasião, a solução foi fazer um CAST para a constante, que tinha tipo NUMERIC para INTEGER. Ao fazê-lo, o tempo caiu VERTIGINOSAMENTE.

Atenciosamente,

Aproveitando sua atitude Willian, gostaria de fazer um rápido comentário: que em discussões comoe esta nós sempre nos lembremos que estamos discutindo não para ter razão, mas para ampliar nossos conhecimentos.
Acredito que até o tom de voz precisa ser diferente. Somos muito ríspidos algumas vezes: "Você está enganado". Poderia ser "Você tem certeza?".
Se o clima respirado aqui for mais ameno vamos nos sertir mais em casa e nossa produtividade melhora.

--
Ribamar FS - ***@ribafs.net
http://ribafs.net
Osvaldo Rosario Kussama
2008-08-06 14:42:40 UTC
Permalink
Post by Paulo
Gostaria de saber ser voces conhecem algum ODBC Postgresql e NATURAL/ADABAS
Por favor não sequestre mensagens, você bagunça o histórico.
Siga a regra: assunto novo, uma nova mensagem.

Das 'Regras das Listas de Discussão" em:
http://www.postgresql.org.br/RegrasLista
"histórico da lista. Eu já repeti isso aqui algumas vezes e outras
pessoas também. É um novo assunto então crie um assunto (e-mail) novo.
Criar um assunto novo não quer dizer clicar em 'Responder' (aka
Reply), apagar o assunto antigo e escrever um novo; isso não remove o
vínculo deste e-mail com o antigo. Para que tenhamos um bom histórico,
não faça isso; "

Osvaldo

Euler Taveira de Oliveira
2008-07-31 04:06:20 UTC
Permalink
Posso dizer, por experiência própria, que o uso de numeric/decimal
só é indicado em casos onde a quantidade de registros é pequeno e/ou não
é usado em processamentos feito pelo banco de dados (qualquer fórmula
e/ou conversão).
Afirmação _sem_ fundamento.
No ano passado, num processo de migração, converti o tipo
decimal(x,y) para o mesmo tipo no postgres, e ao trabalhar com campos
desse tipo em procedimentos, a migração de uma simples tabela de menos
de 500.000 registros durava mais de 20 horas. Ao converter esses campos
para inteiro (pois a parte decimal nem era usada), o tempo de
processamento caiu para 2 minutos. Isso mesmo! Na verdade deve ser menos
que 2 minutos... um absurdo, mas um caso real.
Qual a versão do PostgreSQL? Qual o SO? Duvido que a diferença seja
*tão* discrepante assim mas você tem um script teste que mostre essa
diferença?
--
Euler Taveira de Oliveira
http://www.timbira.com/
William Leite Araújo
2008-08-05 18:34:12 UTC
Permalink
Post by William Leite Araújo
Posso dizer, por experiência própria, que o uso de numeric/decimal
só é indicado em casos onde a quantidade de registros é pequeno e/ou não
é usado em processamentos feito pelo banco de dados (qualquer fórmula
e/ou conversão).
Afirmação _sem_ fundamento.
Ok. Vamos lá. Faça um teste Euler. Execute *SELECT * FROM
[tabela]WHERE [tabela].[chave]
= '1.0'::NUMERIC;*

De preferência em uma tabela onde hajam mais de 1000 registros. Em
seguida, execute a mesma consulta, mas comparando com um inteiro.

Oh.... é muuuuuuuuuuuuito mais lenta. Porquê? A (excelente) documentação
explica:

The type numeric can store numbers with up to 1000 digits of precision and
perform calculations exactly. It is especially recommended for storing
monetary amounts and other quantities where exactness is required. However,
*arithmetic on numeric values is very slow compared to the integer types, or
to the floating-point types described in the next section. *

fonte:
http://www.postgresql.org/docs/8.2/interactive/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL

Ainda sem fundamento?
Post by William Leite Araújo
No ano passado, num processo de migração, converti o tipo
decimal(x,y) para o mesmo tipo no postgres, e ao trabalhar com campos
desse tipo em procedimentos, a migração de uma simples tabela de menos
de 500.000 registros durava mais de 20 horas. Ao converter esses campos
para inteiro (pois a parte decimal nem era usada), o tempo de
processamento caiu para 2 minutos. Isso mesmo! Na verdade deve ser menos
que 2 minutos... um absurdo, mas um caso real.
Qual a versão do PostgreSQL? Qual o SO? Duvido que a diferença seja
*tão* discrepante assim mas você tem um script teste que mostre essa
diferença?
Para compor um único registro eram feitas em torno de 10 consultas dessa
forma, além das 2 consultas de auto-referência (na mesma tabela haviam,
eventualmente, o "pai" e a "mãe" do mesmo).

Assim, os 378,998 registros, sem o cuidado de usar um cast para tipo
inteiro (primeira versão da função) demorou em torno de 20 horas. Após a
otimização foram menos de 2 minutos.

Infelizmente não posso lhe mostrar os dados, mas GARANTO que, tanto num
8.2 quanto num 8.3, você poderá experimentar a diferença no tempo
simplesmente comparando uma constante numeric com uma constante integer.
--
William Leite Araújo
Analista de Banco de Dados - QualiConsult
Shander Lyrio
2008-08-05 19:49:56 UTC
Permalink
Ok. Vamos lá. Faça um teste Euler. Execute /*SELECT* * *FROM*
[tabela]* WHERE *[tabela].[chave] = '1.0'::NUMERIC;/
Sei que era para o Euler fazer o teste mas eu não resisti. Para
começar, que cast mais desnecessário é este que fizestes?? Não seria
mais simples e inteligente algo como:

"select * from tabela where chave = 1.0;"
De preferência em uma tabela onde hajam mais de 1000 registros. Em
seguida, execute a mesma consulta, mas comparando com um inteiro.
Como você informa 1000 registros eu criei uma tabela com 50000 para que
ficasse mais claro esta gritante diferença que o terrível numeric
causaria nas minhas consultas. É claro que eu também me preparei com uma
garrafa de café para passar a noite aqui esperando o retorno delas e
também já avisei minha namorada que eu não iria para casa tão cedo.

Criei a tabela assim:

novo=# create table tablefoo(anytext varchar(100), valor numeric(6,3));;
CREATE TABLE
novo=# create index tablefoo_idx1 on tablefoo(valor);
CREATE INDEX

E gerei os 50000 valores aleatórios com um pequeno script em php assim:

<?php

include "../inc/class/Conexao.inc";

$db = new Conexao();

$db->beginTransaction();
for($i = 0; $i <= 50000; $i++){
$foo = mt_rand(0,10);
$bar = mt_rand(0,999);
$sql = "insert into tablefoo(anytext, valor) values('iteration $i',
$foo.$bar);";
$db->query($sql);
}
$db->commit();

?>
Oh.... é muuuuuuuuuuuuito mais lenta. Porquê? A (excelente)
Para verificar os tempos de resposta eu ativei o timing

novo=# \timing
Timing is on.

Avisei a todos no meu icq e gtalk que eu ficaria off por cerca de 20h
para alguns testes de performance na minha máquina.

novo=# select * from tablefoo where valor = 1.345;
anytext | valor
-----------------+-------
iteration 9094 | 1.345
iteration 10389 | 1.345
iteration 42065 | 1.345
(3 rows)

Time: 0.470 ms
novo=# select * from tablefoo where valor = '1.345'::numeric;
anytext | valor
-----------------+-------
iteration 9094 | 1.345
iteration 10389 | 1.345
iteration 42065 | 1.345
(3 rows)

Time: 0.477 ms
novo=#

Realmente seu casting deixou minha consulta 7 milhonésimos de segundo
mais lenta. Vamos ver casting para float para ter certeza que ele é
lento, parece que não vai dar tempo nem para tomar um café, quanto mais
a garrafa que eu preparei:

novo=# select * from tablefoo where valor = '1.345'::float;
anytext | valor
-----------------+-------
iteration 9094 | 1.345
iteration 10389 | 1.345
iteration 42065 | 1.345
(3 rows)

Time: 90.041 ms

Agora já temos uma enorme diferença, 90 milésimos de segundo.

Vamos pegar a parte inteira de todos os 50000 registros para ver se eu
consigo demorar mais tempo, pelo menos até tomar uma dose de café.

novo=# \o lixo.txt
novo=# select anytext, round(valor) from tablefoo;
Time: 90.500 ms

Poxa, 90 milésimos de segundo para arredondar 50000 registros numéric.
Então vamos tentar converter para o tipo varchar

novo=# select anytext, valor::varchar from tablefoo;
Time: 109.672 ms

Retirar somente a parte inteira dos 50000 registros;

novo=# select anytext, trunc(valor) from tablefoo;
Time: 129.208 ms

Desisto, não vou ter tempo nem para tomar um cafezinho. O PostgreSql
insiste em tratar os 50000 registros com dados numeric em menos de um
décimo de segundo.
Ainda sem fundamento?
Sinto muito cara, mas infelizmente sim.
Para compor um único registro eram feitas em torno de 10 consultas
dessa forma, além das 2 consultas de auto-referência (na mesma tabela
haviam, eventualmente, o "pai" e a "mãe" do mesmo).
Como eu disse, limitação do ambiente, da tecnologia, do seu script de
migração, de falta de modelagem, de qualquer outra coisa que você sonhar
no mundo, menos do PostGreSql. Portanto eu peço que não envie mensagens
com afirmações infundadas e distorcidas para o grupo pois pode
prejudicar quem está começando agora no PostGreSql.
Assim, os 378,998 registros, sem o cuidado de usar um cast para tipo
inteiro (primeira versão da função) demorou em torno de 20 horas. Após a
otimização foram menos de 2 minutos.
Infelizmente não posso lhe mostrar os dados, mas GARANTO que, tanto
num 8.2 quanto num 8.3, você poderá experimentar a diferença no tempo
simplesmente comparando uma constante numeric com uma constante integer.
Opa, isto eu não tinha tentado ainda, vamos lá;

novo=# select * from tablefoo where valor = 1;
anytext | valor
-----------------+-------
iteration 21263 | 1.000
iteration 34970 | 1.000
iteration 37109 | 1.000
iteration 42379 | 1.000
iteration 43073 | 1.000
(5 rows)

Time: 3.568 ms


Poxa, 3 milesegundos comparando com inteiros! Desisto cara, você fez
mágica com sua rotina de migração. Ja liguei para minha namorada e disse
que agente vai poder se ver, ela pediu para te agradecer, agora ainda
estou triste por estragar uma garrafa inteira de cafezinho. Ao menos
tomei um agora no final.

Abraço,

--
Shander Lyrio
William Leite Araújo
2008-08-05 20:16:36 UTC
Permalink
# select version();
version
----------------------------------------------------------------------------------------
PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3
(Debian 4.2.3-2)

#select 1 from xmls_logs where xml_id = '534'::numeric;
?column?
----------
1
(1 registro)

Tempo: 34,068 ms
mobile_card=# select 1 from xmls_logs where xml_id = '534';
?column?
----------
1
(1 registro)

Tempo: 1,475 ms

* Bom, vamos mudar a ordem então:*

#select 1 from xmls_logs where xml_id = '534';
?column?
----------
1
(1 registro)

*Tempo: 4,725 ms*
# select 1 from xmls_logs where xml_id = '534'::numeric;
?column?
----------
1
(1 registro)

*Tempo: 35,339 ms*

Ok. Provavelmente meu servidor não possui otimizações. Mas é para
teste. É para não ter otimizações mesmo. Confesso que, para que o tempo
caísse tanto, aumentei a memória compartinhada e redizí as conexões
simultâneas. Mas o que estou tentando mostrar é o que está na documentação.

Tabela "public.xmls_logs"
Coluna | Tipo |
Modificadores
------------------+------------------------+------------------------------------------------------------
xml_id | integer | not null default
nextval('xmls_logs_xml_id_seq'::regclass)
xml_xml_in | text | not null
xml_xml_out | text |
xml_dsc_tabel | character varying(256) |
xml_int_tabel_id | integer |
xml_dat_tstam | date | not null default
('now'::text)::date
xml_tim_tstam | time without time zone | not null default (now())::time
without time zone
Índices:
"pk_xmls_logs" PRIMARY KEY, btree (xml_id)
Ok. Vamos lá. Faça um teste Euler. Execute /*SELECT* * *FROM*
[tabela]* WHERE *[tabela].[chave] = '1.0'::NUMERIC;/
Sei que era para o Euler fazer o teste mas eu não resisti. Para
começar, que cast mais desnecessário é este que fizestes?? Não seria
"select * from tabela where chave = 1.0;"
De preferência em uma tabela onde hajam mais de 1000 registros. Em
seguida, execute a mesma consulta, mas comparando com um inteiro.
Como você informa 1000 registros eu criei uma tabela com 50000 para
que
ficasse mais claro esta gritante diferença que o terrível numeric
causaria nas minhas consultas. É claro que eu também me preparei com uma
garrafa de café para passar a noite aqui esperando o retorno delas e
também já avisei minha namorada que eu não iria para casa tão cedo.
novo=# create table tablefoo(anytext varchar(100), valor numeric(6,3));;
CREATE TABLE
novo=# create index tablefoo_idx1 on tablefoo(valor);
CREATE INDEX
E gerei os 50000 valores aleatórios com um pequeno script em php
<?php
include "../inc/class/Conexao.inc";
$db = new Conexao();
$db->beginTransaction();
for($i = 0; $i <= 50000; $i++){
$foo = mt_rand(0,10);
$bar = mt_rand(0,999);
$sql = "insert into tablefoo(anytext, valor) values('iteration $i',
$foo.$bar);";
$db->query($sql);
}
$db->commit();
?>
Oh.... é muuuuuuuuuuuuito mais lenta. Porquê? A (excelente)
Para verificar os tempos de resposta eu ativei o timing
novo=# \timing
Timing is on.
Avisei a todos no meu icq e gtalk que eu ficaria off por cerca de 20h
para alguns testes de performance na minha máquina.
novo=# select * from tablefoo where valor = 1.345;
anytext | valor
-----------------+-------
iteration 9094 | 1.345
iteration 10389 | 1.345
iteration 42065 | 1.345
(3 rows)
Time: 0.470 ms
novo=# select * from tablefoo where valor = '1.345'::numeric;
anytext | valor
-----------------+-------
iteration 9094 | 1.345
iteration 10389 | 1.345
iteration 42065 | 1.345
(3 rows)
Time: 0.477 ms
novo=#
Realmente seu casting deixou minha consulta 7 milhonésimos de
segundo
mais lenta. Vamos ver casting para float para ter certeza que ele é
lento, parece que não vai dar tempo nem para tomar um café, quanto mais
novo=# select * from tablefoo where valor = '1.345'::float;
anytext | valor
-----------------+-------
iteration 9094 | 1.345
iteration 10389 | 1.345
iteration 42065 | 1.345
(3 rows)
Time: 90.041 ms
Agora já temos uma enorme diferença, 90 milésimos de segundo.
Vamos pegar a parte inteira de todos os 50000 registros para ver se eu
consigo demorar mais tempo, pelo menos até tomar uma dose de café.
novo=# \o lixo.txt
novo=# select anytext, round(valor) from tablefoo;
Time: 90.500 ms
Poxa, 90 milésimos de segundo para arredondar 50000 registros
numéric.
Então vamos tentar converter para o tipo varchar
novo=# select anytext, valor::varchar from tablefoo;
Time: 109.672 ms
Retirar somente a parte inteira dos 50000 registros;
novo=# select anytext, trunc(valor) from tablefoo;
Time: 129.208 ms
Desisto, não vou ter tempo nem para tomar um cafezinho. O PostgreSql
insiste em tratar os 50000 registros com dados numeric em menos de um
décimo de segundo.
Ainda sem fundamento?
Sinto muito cara, mas infelizmente sim.
Para compor um único registro eram feitas em torno de 10 consultas
dessa forma, além das 2 consultas de auto-referência (na mesma tabela
haviam, eventualmente, o "pai" e a "mãe" do mesmo).
Como eu disse, limitação do ambiente, da tecnologia, do seu script
de
migração, de falta de modelagem, de qualquer outra coisa que você sonhar
no mundo, menos do PostGreSql. Portanto eu peço que não envie mensagens
com afirmações infundadas e distorcidas para o grupo pois pode
prejudicar quem está começando agora no PostGreSql.
Assim, os 378,998 registros, sem o cuidado de usar um cast para tipo
inteiro (primeira versão da função) demorou em torno de 20 horas. Após a
otimização foram menos de 2 minutos.
Infelizmente não posso lhe mostrar os dados, mas GARANTO que, tanto
num 8.2 quanto num 8.3, você poderá experimentar a diferença no tempo
simplesmente comparando uma constante numeric com uma constante integer.
Opa, isto eu não tinha tentado ainda, vamos lá;
novo=# select * from tablefoo where valor = 1;
anytext | valor
-----------------+-------
iteration 21263 | 1.000
iteration 34970 | 1.000
iteration 37109 | 1.000
iteration 42379 | 1.000
iteration 43073 | 1.000
(5 rows)
Time: 3.568 ms
Poxa, 3 milesegundos comparando com inteiros! Desisto cara, você fez
mágica com sua rotina de migração. Ja liguei para minha namorada e disse
que agente vai poder se ver, ela pediu para te agradecer, agora ainda
estou triste por estragar uma garrafa inteira de cafezinho. Ao menos
tomei um agora no final.
Abraço,
Realmente, o seu caso se testes resulta nesses valores...


William Leite Araújo
Analista de Banco de Dados - QualiConsult
Shander Lyrio
2008-08-05 20:33:43 UTC
Permalink
Post by William Leite Araújo
# select version();
version
----------------------------------------------------------------------------------------
PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3
(Debian 4.2.3-2)
#select 1 from xmls_logs where xml_id = '534'::numeric;
?column?
----------
1
(1 registro)
Tempo: 34,068 ms
mobile_card=# select 1 from xmls_logs where xml_id = '534';
?column?
----------
1
(1 registro)
Tempo: 1,475 ms
* Bom, vamos mudar a ordem então:*
#select 1 from xmls_logs where xml_id = '534';
?column?
----------
1
(1 registro)
*Tempo: 4,725 ms*
# select 1 from xmls_logs where xml_id = '534'::numeric;
?column?
----------
1
(1 registro)
*Tempo: 35,339 ms*
Ok. Provavelmente meu servidor não possui otimizações. Mas é para
teste. É para não ter otimizações mesmo. Confesso que, para que o tempo
caísse tanto, aumentei a memória compartinhada e redizí as conexões
simultâneas. Mas o que estou tentando mostrar é o que está na documentação.
Tabela "public.xmls_logs"
Coluna | Tipo |
Modificadores
------------------+------------------------+------------------------------------------------------------
xml_id | integer | not null default
nextval('xmls_logs_xml_id_seq'::regclass)
xml_xml_in | text | not null
xml_xml_out | text |
xml_dsc_tabel | character varying(256) |
xml_int_tabel_id | integer |
xml_dat_tstam | date | not null default
('now'::text)::date
xml_tim_tstam | time without time zone | not null default
(now())::time without time zone
"pk_xmls_logs" PRIMARY KEY, btree (xml_id)
Meu amigo, eu fiz aquilo tudo em meu desktop ubuntu com opções padrão
do postgresql.

Mas agora que mandou a estrutura, o erro está claro, o problema não é
do tipo numeric.

Você tem um campo em sua tabela com o tipo integer, quando você usa
"select 1 from xmls_logs where xml_id = '534';" o postgresql consegue
fazer o casting de string para inteiro e utilizar o índice (somente a
partir da versão 8.0), mas... o postgresql não faz casting automático
de tipo numeric para inteiro (ainda bem que não faz) pois você perderia
precisão dos dados, logo sua segunda consulta não utiliza o índice e por
este motivo demora mais.

Faça o explain das duas consultas que verá que uma vai utilizar o
indice pk_xmls_logs e a segunda não.

Como eu falei antes o erro é de modelagem e não do postGreSql, pois
este trabalha muito bem com tipos numeric, mas ele não faz autocasting
de numeric para integer, nem adivinha intenções obscuras.

ps: Por este motivo eu havia dito para não dar informações categóricas
daquela forma na lista, existem usuários de PostGreSql de níveis bem
diferentes por aqui, uns começando agora, outros já calejados. Espero
que tenha ficado claro, PostGreSql não tem problemas com campos do tipo
numeric, não perde performance na utilização deles. Se ainda restar
alguma dúvida, icq: 71366121

Abraço e boa sorte,

--
Shander Lyrio
Loading...