Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
2008/8/6 William Leite Araújo [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
2008/7/31 Euler Taveira de Oliveira [EMAIL PROTECTED] William Leite Araújo escreveu: 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 é mito 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? 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
2008/7/30 Shander Lyrio [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 Leite Araújo Analista de Banco de Dados - QualiConsult ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
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
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
William Leite Araújo wrote:
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 5 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 5 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 = 5; $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 é mito mais lenta. Porquê? A (excelente)
documentação explica:
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 5 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 5 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 5 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 5 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
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
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,5); 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* 2008/8/5 Shander Lyrio [EMAIL PROTECTED] Osvaldo Rosario Kussama wrote: 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? Matou a questão do cache de páginas de forma muito mais elegante Osvaldo, preciso aprender contigo. -- Shander Lyrio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
William Leite Araújo wrote:
# 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)
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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
William Leite Araújo wrote: 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
Evandro Ricardo Silvestre wrote: 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
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). 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. 2008/7/29 Ribamar Sousa [EMAIL PROTECTED] 2008/7/29 Glauber Almeida [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
2008/7/30 William Leite Araújo [EMAIL PROTECTED] 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. 2008/7/29 Ribamar Sousa [EMAIL PROTECTED] 2008/7/29 Glauber Almeida [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
William Leite Araújo wrote: 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-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
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 [EMAIL PROTECTED] To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Sent: Wednesday, July 30, 2008 2:39 PM Subject: Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC William Leite Araújo wrote: 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-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
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
Em 30/07/08, Celso[EMAIL PROTECTED] escreveu: 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar? REAL, DOUBLE PRECISION e NUMERIC
William Leite Araújo escreveu: 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/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
