havia perdido a formatação
>CREATE OR REPLACE FUNCTION roundUp(valor numeric, qtDec integer)>RETURNS >
>numeric>AS $$>DECLARE> auxNum numeric;> auxInt integer;> auxStr
>varchar;>BEGIN> select round(valor, qtDec + 1) into auxNum;> select
>cast(substring(cast(auxNum as varchar) from (position('.' in cast(auxNum as
>varchar)) + qtDec + 1) for 1) as integer) into auxInt;>> if (auxInt > 0)
>then> select trunc(valor + cast(('0.' || repeat('0', qtDec - 1) ||
>1) as numeric),qtDec) into auxNum;> else > select
>trunc(valor,qtDec) into auxNum;> end if;> return auxNum;>END;>$$
>LANGUAGE plpgsql;>>select roundUp(1.123112,3)
Joel R. Benelli
> From: [email protected]
> Subject: Digest pgbr-geral, volume 50, assunto 15
> To: [email protected]
> Date: Fri, 8 Feb 2013 23:25:26 -0200
>
> Send pgbr-geral mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pgbr-geral digest..."
>
>
> Tópicos de Hoje:
>
> 1. RES: Round Unidade Superior (Paulo)
> 2. Re: Ref: Round Unidade Superior. (Dickson S. Guedes)
> 3. Re: ÍNDICES EM TABELAS QUE RECEBEM MUITOS INSERTS, UPDATES
> (Dickson S. Guedes)
> 4. RES: Ref: Round Unidade Superior. (Paulo)
> 5. Re: Function atualiza valor com nulo (Dickson S. Guedes)
> 6. Re: ÍNDICES EM TABELAS QUE RECEBEM MUITOS INSERTS, UPDATES
> (Flavio Henrique Araque Gurgel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Feb 2013 18:12:50 -0200
> From: "Paulo" <[email protected]>
> Subject: [pgbr-geral] RES: Round Unidade Superior
> To: "'Comunidade PostgreSQL Brasileira'"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Show de bola Joel,
>
>
>
> Funcionou exatamente como o esperado.
>
> Obrigado a todos que responderam.
>
>
>
> Abraços a todos.
>
>
>
> Paulo.
>
> vp_logo
>
> [email protected]
>
>
>
>
>
> De: [email protected]
> [mailto:[email protected]] Em nome de Joel R.
> Benelli
> Enviada em: sexta-feira, 8 de fevereiro de 2013 17:36
> Para: postgres list
> Assunto: Re: [pgbr-geral] Round Unidade Superior
>
>
>
> e ai Paulo, segue uma solução, se a unidade anterior ao decimal informado
> for maior que zero, soma 1 na unidade decimal informada.
>
>
>
> CREATE OR REPLACE FUNCTION roundUp(valor numeric, qtDec integer)
>
>
>
> select roundUp(1.123102,3);
>
>
>
> até mais
>
>
> Joel R. Benelli
>
> -------------- Próxima Parte ----------
> Um anexo em HTML foi limpo...
> URL:
> http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20130208/12a41698/attachment-0001.htm
>
> -------------- Próxima Parte ----------
> Um anexo não texto foi limpo...
> Nome : não disponível
> Tipo : image/jpeg
> Tam : 1788 bytes
> Descr.: não disponível
> Url :
> http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20130208/12a41698/attachment-0001.jpeg
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Feb 2013 21:48:31 -0200
> From: "Dickson S. Guedes" <[email protected]>
> Subject: Re: [pgbr-geral] Ref: Round Unidade Superior.
> To: Comunidade PostgreSQL Brasileira
> <[email protected]>
> Message-ID:
> <cahhcrerrbfr7sh0nijaoyloynywu_jgqppmf5rwp+8bkxpr...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Em 8 de fevereiro de 2013 15:22, Paulo <[email protected]>
> escreveu:
> > Ola Pessoal,
> >
> > Como posso forçar um arredondamento para unidade superior,
> > Por Ex:
> >
> > SELECT ROUND(115.00/12,2); Retorno: 9.58,
> >
> > Se multiplicar por 12 * 9.58 = 114,96
> >
> > Preciso forçar retorno 9.59 * 12 = 115,08
> >
> > Alguma ideia ?
>
> Você diz que precisa "forçar o retorno", então creio que na real você
> precise considerar mais casas decimais em seus cálculos, então vou
> considerar que voce quer levar em consideração até a terceira casa
> após à v?igula logo você precisa i) carregar o ponto flutuante no seu
> cálculo (ou seja, não arredonde antes) ou ii) somar 0.004 e arredondar
> depois
>
> Eu vou optar pela opção ii:
>
> postgres=# select round((115.00/12) + 0.004,2);
> round
> -------
> 9.59
>
> postgres=# select round(9.58333333333333 + 0.004,2);
> round
> -------
> 9.59
>
> postgres=# select round(9.5891 + 0.004,2);
> round
> -------
> 9.59
>
> postgres=# select round((115.00/12) + 0.005,2) * 12;
> ?column?
> ----------
> 115.08
>
> Já que você está considerando apenas 2 (duas) casas após à vírgula o
> uso do 0.004 torna-se desprezível para a operação como um todo, mas
> não para o round. Em outras palavras você vai "forçar" ele arredondar
> sempre que você tiver, no mínimo, 0.001, já que este, somado aos 0.004
> chega aos 0.005 que arrendondado vai para 0.01.
>
> Se não for isso o que você precisa, eu não entendi sua pergunta.
>
> []s
> --
> Dickson S. Guedes
> mail/xmpp: [email protected] - skype: guediz
> http://github.com/guedes - http://guedesoft.net
> http://www.postgresql.org.br
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 8 Feb 2013 22:02:59 -0200
> From: "Dickson S. Guedes" <[email protected]>
> Subject: Re: [pgbr-geral] ÍNDICES EM TABELAS QUE RECEBEM MUITOS
> INSERTS, UPDATES
> To: Comunidade PostgreSQL Brasileira
> <[email protected]>
> Message-ID:
> <CAHHcreomfRaj-G98JmR8KYkfG2YpqmNUQ2DOYgs56=fle+c...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Em 8 de fevereiro de 2013 09:47, Wellington Openheimer
> <[email protected]> escreveu:
> [... corte ...]
> > Decidimos então testar a criação de uns índices com os principais campos nas
> > cláusulas WHERE das consultas mais lentas.
> >
> > A consulta ficou bem mais rápida, mas estamos receosos se estes índices irão
> > deixar mais lenta a inserção e update de dados
> > pois esses comandos teriam então que inserir no índice também.
>
> Como o Flávio falou em outro e-mail, sim os índices vão deixar mais
> lentos os UPDATES e INSERTs por exemplo, mas a questão que você
> precisa levar em consideração é se este tempo pode ser desprezado.
> Veja, você percebeu uma lentidão na consulta, atuou pontualmente com
> um índice e minimizou os eu problema, você otimizou quando precisou.
>
> Sendo assim não se preocupe neste momento com o tempo de inserção a
> menos que ele comece a ser um problema para o seu ambiente. Neste
> caso, uma alternativa poderia ser o uso de tablespaces separando estes
> índices específicos em outros discos, de preferência discos mais
> rápidos ou até mesmo ramdisks. Mas isto não é uma regra, é apenas um
> exemplo de uma alternativa caso você perceba problemas.
>
> []s
> --
> Dickson S. Guedes
> mail/xmpp: [email protected] - skype: guediz
> http://github.com/guedes - http://guedesoft.net
> http://www.postgresql.org.br
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 8 Feb 2013 22:07:53 -0200
> From: "Paulo" <[email protected]>
> Subject: [pgbr-geral] RES: Ref: Round Unidade Superior.
> To: "'Comunidade PostgreSQL Brasileira'"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Muito bom, bom mesmo.
> Obrigado Dickson.
>
> Att,
>
> Paulo.
>
> Eu vou optar pela opção ii:
>
> postgres=# select round((115.00/12) + 0.004,2);
> round
> -------
> 9.59
>
> postgres=# select round(9.58333333333333 + 0.004,2);
> round
> -------
> 9.59
>
> postgres=# select round(9.5891 + 0.004,2);
> round
> -------
> 9.59
>
> postgres=# select round((115.00/12) + 0.005,2) * 12;
> ?column?
> ----------
> 115.08
>
> Já que você está considerando apenas 2 (duas) casas após à vírgula o
> uso do 0.004 torna-se desprezível para a operação como um todo, mas
> não para o round. Em outras palavras você vai "forçar" ele arredondar
> sempre que você tiver, no mínimo, 0.001, já que este, somado aos 0.004
> chega aos 0.005 que arrendondado vai para 0.01.
>
> Se não for isso o que você precisa, eu não entendi sua pergunta.
>
> []s
> --
> Dickson S. Guedes
> mail/xmpp: [email protected] - skype: guediz
> http://github.com/guedes - http://guedesoft.net
> http://www.postgresql.org.br
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 8 Feb 2013 22:10:31 -0200
> From: "Dickson S. Guedes" <[email protected]>
> Subject: Re: [pgbr-geral] Function atualiza valor com nulo
> To: Comunidade PostgreSQL Brasileira
> <[email protected]>
> Message-ID:
> <CAHHcreruNdsE3WssjbtsCXQJNbO1v=-uen+y7x5srbkzvfr...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2013/2/8 Edson - Lista <[email protected]>:
> > Em 08/02/2013 11:23, Wolak escreveu:
> >> COALESCE(vlr_saldo,0) +
> >> COALESCE(old.vlr_pgto,0).
> > também não deu certo.
>
>
> Coloque alguns RAISE DEBUG 'x=%, y=%, ....', NEW.x, NEW.y, ....; pelo
> seu código dentro dos IFs, mude o nível de log do cliente para DEBUG e
> acompanhe os resultados para ver onde estão vindo os NULLs.
>
> []s
> --
> Dickson S. Guedes
> mail/xmpp: [email protected] - skype: guediz
> http://github.com/guedes - http://guedesoft.net
> http://www.postgresql.org.br
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 8 Feb 2013 23:28:05 -0200 (BRST)
> From: Flavio Henrique Araque Gurgel <[email protected]>
> Subject: Re: [pgbr-geral] ÍNDICES EM TABELAS QUE RECEBEM MUITOS
> INSERTS, UPDATES
> To: Comunidade PostgreSQL Brasileira
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=utf-8
>
> > Essa é a chave da tabela:
> > pk_tb_matricula PRIMARY KEY(matr , cursocod , gradecod , disccodof , periodo
> > , ano );
> >
> > Esses são os 2 índices que fizeram diferença na execução da consulta do
> > programa:
> > CREATE INDEX turma_teo
> > ON tb_matricula
> > USING btree
> > (turmateo COLLATE pg_catalog."default" , ano , periodo );
> >
> > CREATE INDEX turmapra_idx
> > ON tb_matricula
> > USING btree
> > (turmapra COLLATE pg_catalog."default" , ano , periodo );
> >
> > Esta é a consulta complicada:
> > O problema é que o programa faz um FOR nesta consulta, pois é um count de
> > cada turma.
> >
> > explain analyze SELECT COUNT(*)
> > FROM TB_MATRICULA
> > WHERE DISCCODOF= 'ADM082' AND
> > LOCALCOD = 'C01' AND
> > ((REGIME = 'A' AND ANO = 2012) OR
> > (REGIME !='A' AND ANO = 2012 AND PERIODO = 1)) AND
> > (TURMATEO = 'X') OR
> > ('TURMAPRA = 'Y'));
> >
> > Esse foi o resultado do Explain:
> > "Aggregate (cost=4835.89..4835.90 rows=1 width=0) (actual
> > time=39.486..39.486
> > rows=1 loops=1)"
> > " -> Index Scan using pk_tb_matricula on tb_matricula (cost=0.00..4835.02
> > rows=351 width=0) (actual time=0.190..39.231 rows=1520 loops=1)"
> > " Index Cond: (((disccodof)::text = 'ADM082'::text) AND (ano = 2012))"
> > " Filter: ((localcod = 'C01'::bpchar) AND (((turmateo)::text = '1'::text) OR
> > ((turmapra)::text = ''::text)) AND ((regime = 'A'::bpchar) OR ((regime <>
> > 'A'::bpchar) AND (periodo = 1))))"
> > "Total runtime: 39.591 ms"
>
> Bom, veja seu plano de execução:
> A consulta usou apenas o índice da chave primária (pg_tb_matricula).
> A consulta levou pouco mais de 39 ms para executar, obteve uma linha
> agregando 4835 (por causa do count) e fim, dentre
> Portanto, os índices turmapra_idx e turma_teo, para essa consulta em
> específico, não estão sendo utilizados.
>
> Considere removê-los e veja se o plano de execução muda (faça outro EXPLAIN
> ANALYZE sem os índices).
> Se o plano *não* mudar (não deve mudar, porque o índice usado foi o da pk),
> simplesmente fique sem os índices exceto a própria chave primária. Claro que
> não estou considerando outras consultas que você pode ter em seu sistema.
>
> 39 ms me parece um tempo excelente para execução de uma consulta com count(*).
> Você disse que faz um laço em seu programa (for) e executa a consulta várias
> vezes. Quantas vezes?
> Não dá pra trocar o laço por uma consulta mais elaborada e deixar o banco de
> dados fazer isso por você?
>
> Outra coisa interessante, qual versão do PostgreSQL está usando?
> Na versão 9.2.x você tem o recurso index_only_scan que pode melhorar o
> desempenho dessa consulta em umas... 10 ou 12 vezes. Não que você precise
> disso, claro.
>
> []s
>
> __________________________________
> Flavio Henrique A. Gurgel
> Líder de Projetos Especiais
> Consultoria, Projetos & Treinamentos 4LINUX
> Tel1: +55-11.2125-4747 ou 2125-4748
> www.4linux.com.br
> email: [email protected]
> ______________________________
> FREE SOFTWARE SOLUTIONS
>
>
> ------------------------------
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
> Fim da Digest pgbr-geral, volume 50, assunto 15
> ***********************************************
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
