Re: [pgbr-geral] Views materializadas

[Claudio Bezerra Leopoldino]

É preciso disparar a atualização com o comando REFRESH: PostgreSQL: 
Documentation: 9.4: REFRESH MATERIALIZED VIEW
|   |
|   |  |   |   |   |   |   |
| PostgreSQL: Documentation: 9.4: REFRESH MATERIA...PostgreSQL 9.4.1 
Documentation Prev Up Next REFRESH MATERIALIZED VIEW NameREFRESH MATERIALIZED 
VIEW -- replace the contents of a materialized vi... |
|  |
| Visualizar em www.postgresql... | Visualizado por Yahoo |
|  |
|   |

  

Cordialmente,
Cláudio Leopoldino
postgresqlbr.blogspot.com/
= 

 Em Segunda-feira, 23 de Fevereiro de 2015 8:04, Luiz Carlos L. Nogueira 
Jr.  escreveu:
   

 Pessoal,
Quando criamos uma view materializado no postgres, ela se atualiza quando?
Luiz Carlos
___
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] Divisão

[Claudio Bezerra Leopoldino]

Eu costumo explicitar as decimais ou multiplicar por 1.00 para manter a parte 
fracionária.
Exemplo: 

SELECT 100.00/5.00; ouSELECT 100*1.00/5*1.00;
Cordialmente,
Cláudio Leopoldino
postgresqlbr.blogspot.com/
= 

 Em Quarta-feira, 7 de Janeiro de 2015 14:24, JotaComm 
 escreveu:
   

 Opa,

Em 7 de janeiro de 2015 15:07, Matheus Ferreira  
escreveu:

Boa tarde pessoal Como faço dentro do select uma divisão dentro do select...

​Não entendi o seu questionamento.​ 
 SELECT (nrfaturamento / vlreceitafaturamento) as mediaFrom Faturamento 
AttMatheus Ferrreira


|  |   Este email foi escaneado pelo Avast antivírus. 
www.avast.com   |



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




​Abraços​
-- 
JotaComm
http://jotacomm.wordpress.com
___
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] Insert via plsql function

[Claudio Bezerra Leopoldino]

Sugiro que você faça esta operação após a matrícula ser concluída.
Caso você faça uma matrícula, mas alunos possam entrar no meio do curso, isso 
não vai funcionar. Neste caso, crie uma trigger para fazer essa inserção a cada 
aluno que for incluído (AFTER INSERT).
Cordialmente,
Cláudio Leopoldino
postgresqlbr.blogspot.com/
= 

 Em Quarta-feira, 12 de Novembro de 2014 9:51, Erison Gmail 
 escreveu:
   

  Bom dia    Preciso que o banco autoalimente uma 
tabela, em função dotempo    Vou passar a idéia,     Preciso que quando o dia 
for letivo (tabela onde estagravados os dias letivo) o sistema lance presença 
padrão sim para todos osalunos que esteja matriculados.    Os usuários do 
sistema depois somente informarão as faltas.    Se alguém tiver uma sugestão, 
exemplo, idéia agradeço    Obrigado(a),     Erison Roberto Belon
Técnólogo em processamento de dados Bacharel em desenvolvimento de software 
para web
email:
  nos...@gmail.com skype:
  nosireerb  nosireig
ICQ:
   609535756
fone:
 55(17)99714-9152 (VIVO) 55(17)98214-4666 (TIM) 
55(17)99152-7335 (CLARO)         


|  |   Este email foi escaneado pelo Avast antivírus. 
www.avast.com   |



___
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] Ferramenta Gráfica para PostgreSql

[Claudio Bezerra Leopoldino]

Uma boa alternativa é o squirrel client. Utilizo com bons resultados no Linux:

http://squirrel-sql.sourceforge.net/

Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=


Em Segunda-feira, 2 de Junho de 2014 15:41, "Guimarães Faria Corcete DUTRA, 
Leandro"  escreveu:
 


2014-06-01 14:16 GMT-03:00 Edson F. Lidorio :
>
> Que ferramenta gráfica para comandos SQL, vocês utilizar para trabalhar com
> PostgreSql em Linux?

Emacs 24 com modo SQL.

Mas os comandos são texto; que funções você quer da ferramenta?


-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
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] [OFF-TOPIC] Normalização de dados.

[Claudio Bezerra Leopoldino]

Bom dia!

Meu caro, sugiro que adiciona os campos na tabela, e que só tente fazer 
otimizações e ajustes de performance caso seja percebida alguma lentidão.

Primeiro se implementa o sistema, depois ajusta-se o que é necessário.


Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=


Em Sexta-feira, 30 de Maio de 2014 10:24, C.P.D. - T.I. MoRHena 
 escreveu:
 


Prezados,

Sou analista de sistemas desenvolvedor e preciso criar dois atributos 
dentro de uma tabela já existente. Acontece que para estes dois 
atributos [varchar=30] cerca de 70% dos seus lançamentos o valor será 
nulo. A questão que me deixa em dúvida é, crio estes dois campos na 
tabela já existente mesmo sabendo do alto percentual de registros com o 
valor nulo ou crio uma nova tabela relacionada a esta já existente com 
apenas estes dois atributos ?

Abraços,

Olavo Jr.

---
Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus 
está ativa.
http://www.avast.com

___
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] Utilização do Postgresql no Brasil e Exterior

[Claudio Bezerra Leopoldino]

Existem alguns sites que podem ajudar a ver comparativos e tendências.

Google trends: 

- http://postgresqlbr.blogspot.com.br/search?q=google+trends
- http://www.google.com.br/trends/


DB-ENGINES: 
- 
http://postgresqlbr.blogspot.com.br/2013/03/qual-e-o-sgbd-mais-popular-o-postgresql.html

- http://db-engines.com/en/ranking

Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/



Em Quinta-feira, 29 de Maio de 2014 17:48, André Geraldo dos Santos 
 escreveu:
 


Caros
Boa noite.

Estou fazendo um trabalho e necessito apontar alguns casos de sucesso do 
Postgresql a nível nacional e internacional.

Onde encontro essas informações?
Se possível publicações de teste de performance e carga de dados.

Aguardo retorno e qualquer dúvida estou à disposição.

-- 


Atenciosamente,


André Geraldo dos Santos
Certified Delphi® Developer XE2 
Analista Desenvolvedor e Consultor
Belo Horizonte / Minas Gerais
E-mail:andresanto...@gmail.com
E-mail:andresan...@modulartecnologia.com.br
Telefone : +55 31 3047-6506 8746-9651

Skype : modulartecnologia_andre
___
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] Modelagem com problema

[Claudio Bezerra Leopoldino]

Em Sexta-feira, 11 de Abril de 2014 20:39, Douglas Fabiano Specht 
 escreveu:
 





Em 26 de março de 2014 19:19, Guimarães Faria Corcete DUTRA, Leandro 
 escreveu:

2014-03-26 18:15 GMT-03:00 Douglas Fabiano Specht :
>
>>
>> Em 26 de março de 2014 18:00, Guimarães Faria Corcete DUTRA, Leandro
>>  escreveu:
>
>>> Mas parece mais um caso para particionamento.
>>>
>> Mas o particionamento de tabela é horizontalmente(dados), precisava
>> particionar verticalmente(colunas)
>
>Mas tua descrição do que querias falava em volume excessivo de dados.
>Isso se resolve com particionamento, a menos que você possa normalizar
>a base — e mesmo assim pode ainda precisar de particionamento.
>
>Visões e gatilhos podem ajudar a dividir em atributos sem normalizar,
>ou até normalizando, mas dá mais trabalho para evitar mudar o
>aplicativo.
>
>
>
>--
>skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
>+55 (61) 3546 7191              gTalk: xmpp:leand...@jabber.org
>+55 (11) 9406 7191        ICQ/AIM: aim:GoIM?screenname=61287803
>BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>___
>pgbr-geral mailing list
>pgbr-geral@listas.postgresql.org.br
>https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
Boa anoite galera,
para finalizar o post e colocar a solução, para futuras pesquisas, vou utilizar 
herança (inherit), onde vou pegar a tabela docfiscal por exemplo que possui 
atualmente 124 campos, e dividi-la em 2 de 62, onde a tabela filha irá se 
chamar docfiscal, e a pai docfiscal_pai.
como por herança a tabela filha herda os objetos do pai, desta maneira irá 
ficar totalmente transparente para aplicação ou usuário, pois quando fizer um 
insert, update, delete, ou um select, sempre faço na docfiscal, que ira trazer 
os seus objetos mais os objetos da docfiscal_pai. Deixamos os desenvolvedores 
felizes [1], quando conseguimos arrumar algo feito por eles e que 
principalmente nao irao precisar implementar nada.

[1]. Dessa maneira me resolve a questão de tabelas onde os programadores se 
"empolgaram" no modelo ER.
Ja para particionar essas tabelas quando o volume de registros chegar em torno 
de uns 10.000.000 de registros, ainda vou pensar, mas acho que fazer trigger 
por data é o que mais convêm, mas também deve ser transparente para a 
aplicação, logo vou ainda estudar um pouco mais

Uma pergunta mais voltado ao pessoal que trabalha com modelagem. Existe alguma 
regra ou sujestão\boas praticas de quantidade de campos para uma tabela? algum 
link\documento??



-- 



Douglas Fabiano Specht

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Amigo, boa tarde!

Ao se fazer o particionamento "vertical" de uma tabela, dividindo-a em dois 
grupos de colunas, você deve levar em conta não só o seu número e tamanho, mas 
também o bom senso. 

Normalmente se separa a tabela em uma relação com os atributos mais acessados e 
obrigatórios, e outra tabela com os atributos menos necessários e opcionais. 
Desta forma reduz-se a necessidade de fazer junções.

Analise se a herança resolve o seu problema, ou se visões ou visões 
materializadas poderiam ser empregadas de forma satisfatória.

Cordialmente,

Cláudio Leopoldino
postgresqlbr.blogspot.com/___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho de uma linha e de um campo

[Claudio Bezerra Leopoldino]

Se o tipo é tradicional, você pode consultar a tabela pg_type e procurar o 
tamanho pelo typname:

select * from pg_type
Se você não conhece o tipo, crie uma tabela com apenas uma linha e uma coluna 
deste tipo, e use o comando EXPLAIN:

EXPLAIN SELECT codigo FROM cliente LIMIT 1;

O resultado apresenta o tamanho de cada linha em bytes!

 
Cordialmente,

Cláudio Leopoldino
postgresqlbr.blogspot.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SQL Art

[Claudio Bezerra Leopoldino]

Alegrou a minha tarde, heheheh!

Cordialmente, 


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=
Em Quarta-feira, 2 de Abril de 2014 13:37, Flavio Henrique Araque Gurgel 
 escreveu:
 


Em 02-04-2014 18:30, Fábio Telles Rodriguez escreveu:
> Roda aí
>
> select * from
> (select array_to_string(array_agg(CASE WHEN 
> (power((xx.x-25),2)/130+power((yy.y-25),2)/130)=1 THEN '$' WHEN 
> (sqrt(power(xx.x-20,2)+power(yy.y-20,2)))<2 THEN '#' WHEN 
> (sqrt(power(xx.x-20,2)+power(yy.y-30,2)))<2 THEN '#' WHEN 
> (sqrt(power(xx.x-29,2)+power(yy.y-25,2)))<4 THEN '#' WHEN 
> (power((xx.x-10),2)/40+power((yy.y-10),2)/40)=1 THEN '$' WHEN 
> (power((xx.x-10),2)/40+power((yy.y-40),2)/40=1) THEN '$' ELSE ' ' END),' ') 
> as cartoon from
>
>
> (select generate_series(1,40) as x) as xx,(select generate_series(1,50) as y) 
> as yy group by xx.x order by xx.x) as co_ord;
>
> Tem a manha de fazer um melhor?
>
> http://feedproxy.google.com/~r/blogspot/rFRqt/~3/oTGb8aK0Qt4/cartoon-in-pg.html
> 

Cool!
[]s
Flavio Gurgel
___
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] Diferenças de performance rodando funcao

[Claudio Bezerra Leopoldino]

Em Segunda-feira, 10 de Fevereiro de 2014 12:48, Fabio Barros 
 escreveu:
 
From: fabi...@hotmail.com
To: pgbr-geral@listas.postgresql.org.br
Date: Fri, 7 Feb 2014 14:57:06 +
Subject: [pgbr-geral] Diferenças de performance rodando funcao

 
Boa tarde pessoal!

Estou tentando entender a diferença de performance em duas implementações que 
fazem a mesma coisa, mas ainda não consegui achar uma explicação.

Segue abaixo os dois exemplos, caso alguém possa me ajudar no entendimento:

Tenho um arquivo texto de 12 mil linhas, parte do conteudo abaixo:

SELECT aux_ir_gao_generico ('I', 39700, '1621', '39700', 0);
SELECT aux_ir_gao_generico ('I', 39700, '1622', '39700', 0);
. . .
SELECT aux_ir_gao_generico ('I', 39700, '1623', '39700', 0);
SELECT aux_ir_gao_generico ('I', 39700, '1624', '39700', 0);

*** Fiz um programa C++ que simplesmente lê o arquivo e executa cada uma de 
suas linhas, a seguir:

main(){

  time_t now;
  char l_comando_sql[C_TAM_MAX_LINHA+1];
  int resultado_st;
  FILE* a_arq_executado;

  PGconn   *l_conexao = PQconnectdb(dbname=bd_vas user=vas_user);
  PGresult *l_result;

  now = time(0);
  std::cout << "tempo inicial=" << now << std::endl;

  a_arq_executado = fopen (C_NOME_ARQ_EXECUTADO, "r");
  fseek (a_arq_executado, 0, SEEK_SET);

  for(int cont_linha = 1; (fgets(l_comando_sql, sizeof(l_comando_sql), 
a_arq_executado) != NULL); cont_linha++){
    l_result = PQexec(l_conexao, l_comando_sql); -- comentando esta linha, fica 
instantaneo (nao é problema ao ler o arquivo)
  }

  now = time(0);
  std::cout << "tempo final=" << now << std::endl;
  
}

*** No outro teste, fiz uma funcao postgres e 'embuti' as mesmas queries, a 
seguir:

CREATE FUNCTION insere_gao_mult () RETURNS INTEGER AS'
DECLARE
  l_retorno INT;
BEGIN

SELECT into l_retorno aux_ir_gao_generico (''I'', 39700, ''1621'', ''39700'', 
0);
SELECT into l_retorno aux_ir_gao_generico (''I'', 39700, ''1622'', ''39700'', 
0);
-- omitindo as outras linhas, só 12 mil dentro de uma funcao... rs
SELECT into l_retorno aux_ir_gao_generico (''I'', 39700, ''1623'', ''39700'', 
0);
SELECT into l_retorno aux_ir_gao_generico (''I'', 39700, ''1624'', ''39700'', 
0);

  RETURN 0;

END;
' LANGUAGE 'plpgsql';

Rodei um script .sh para chamar a funcao acima.

Tempo do programa C++..: 1 minuto
Tempo executando a funcao q contem as linhas do arquivo: 3 segundos

Particularmente, acho muito interessante este tipo de dúvida, e por isso 
resolvi postar aqui

Pq toda essa diferença no tempo?!?!?! (desculpem a ignorância)

obs: não vou ter funções como a do meu exemplo, é apenas para tentar entender 
alguns conceitos.

Grato,
Fabio Barros
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Boa tarde!!!

Pessoal, estou lendo sobre as dúvidas destes dias, e acredito que meu e-mail 
acima acabou 'passando'.

Vcs teriam algo a comentar sobre minha dúvida?

Obrigado e desculpem por pedir novamente, mas já acrescentando outra pergunta: 
faz sentido, em função dessa diferença de tempo, adotar algo do tipo como 
solução?!?!

obs: onde trabalho tb não há DBA Postgresql, e talvez eu seja quem mais conhece 
sobre o banco aqui (porém pouco), mas minha 'facilidade' é mais em modelagem, 
montagem de queries e funções e muito menos em administração, mas as 
pessoas confundem.

Grato,
Fabio Barros






___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
=
Fábio, desculpe a demora na resposta.

A implementação em C é rápida, mas cada comando de banco de dados em sql 
submetido passa por análise léxica e sintática, geração e otimização de plano 
de execução para ser executado. 

Na implementação com funções os comandos são armazenados em um formato não tão 
eficaz quanto o códico compilado em C, mas já passaram pela análise e 
otimização para o banco de dados, tendendo a serem bem rápidos. 

Já que estás lendo os comandos de modo texto, sugiro que teste com o comando 
COPY e traga o resultado para a lista: 
http://www.postgresql.org/docs/9.3/static/sql-copy.html

Cordialmente, 


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda Manutenção Base de dados Postgre 9.0

[Claudio Bezerra Leopoldino]

As hipóteses para o seu problema, são:

1- Migração de dados do Nexus para o postgresql trouxe dados duplicados ou 
errados. Creio que não se aplica neste caso, pois depois de um anos já teria 
sido descoberto;
2- Os dados que estão sendo inseridos, alterados e excluídos estão incorretos. 
Rever as rotinas de modificação de dados no banco;
3- As consultas realizadas não estão utilizando os filtros e junções corretos. 
Auditar consultas;
4- As consultas realizadas estão utilizando níveis de isolamento muito 
flexíveis. Rever as configurações para "Transact isolation levels". 

Creio que as hipóteses 2, 3 e 4 são as mais prováveis.

O vacuum vai ter dar melhor aproveitamento do espaço de armazenamento e maior 
rapidez nos acessos aos dados, mas não vai melhorar a consistência da sua base 
de dados.

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



Em Segunda-feira, 10 de Fevereiro de 2014 7:53, "Guimarães Faria Corcete DUTRA, 
Leandro"  escreveu:
 
2014-02-10 Thiago Haroldo :
>
> Não, eu não deixei ele ligado, pois queria saber mais informações sobre o
> mesmo.

Não altere as configurações padrão sem ter idéia do que está fazendo.
Um ano sem limpeza da base (é isso que a ‘aspiração’ [/vaccuum/] faz)
é temerário.


> Qual a versão do PostgreSQL que está usando?
>
> Estou usando a Versão 9.0

Alguma razão para uma base que tem apenas um ano usar uma versão tão
antiga?  Pelo menos atualize imediatamente para a última 9.0.X, que é
a 9.0.15, porque isso é essencial e geralmente só exige a leitura das
notas de versão (/release notes/), e já vá planejando atualizar para a
9.3 ou, idealmente, a futura 9.4, porque a 9.0.X deixará de ser
suportada ano que vem e a gente nunca sabe as intercorrências que
podem atrasar uma atualização.


> Porem estou achando estranho é que algumas vezes geramos relatórios no
> sistema e ele traz  algumas informações erradas...

Então o que precisas é nos trazer, pelo menos, um exemplo de consulta,
estrutura das relações (tabelas) consultadas, dados de origem e
resultados obtidos e esperados.  Isso nada tem a ver com manutenção da
base, a princípio.


> Achei que poderia ser
> sujeira na base de dados... Rodando o Vaccum resolveria nossos problemas...

Não, a limpeza não altera resultados.  A menos que tua base esteja tão
podre que os dados estejam inconsistentes, mas aí daria tanto problema
que já nos terias procurado há meses.



> Obs: Não sou DBA, mas tenho que me virar, pois a empresa onde trabalho não é
> de grande porte e não tem um profissional destinado a este serviço.

Por isso mesmo tinhas de nos ter procurando antes de desligar algo tão
essencial quanto a limpeza automática da base.


-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm

___
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] Troca SQL no Banco

[Claudio Bezerra Leopoldino]

Você pode utilizar triggers para isso, mas apenas para INSERT, DELETE, UPDATE e 
TRUNCATE. Elas podem executar INSTEAD (no lugar do) código submetido. 

O ideal é tratar na aplicação.

Você poderia criar uma função que tivesse um IF, pasando as consultas como 
parâmetro. Se a consulta fosse de determinado tipo, você altraria o comando 
efetivamente realizado. No entanto, não sei que impacto esta operação teria no 
desempenho, pois todas as consultas suspeitas teria de ser submetidas via 
função.

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



Em Quinta-feira, 30 de Janeiro de 2014 0:03, Tiago Adami  
escreveu:
 
Em 29 de janeiro de 2014 22:29, Daviramos Roussenq Fortunato
 escreveu:
> Em 29 de janeiro de 2014 22:27, Rafael Fialho Corrêa 
> escreveu:
>> Em 29 de janeiro de 2014 22:16, Daviramos Roussenq Fortunato
>>  escreveu:
>>
>>> (corte)
>>
>> Alguma gambiarra com views de repente?
>>
> Sim pensei em algo assim, mas não posso peder outros SELECT nessa mesma
> tabela que são feitos de outra forma exemplo "SELECT * FROM CLIENTES".

Desconheço qualquer SGBD que faça isso. E muito cuidado com este tipo
de abordagem. Como projetista já trabalhei em uma empresa que sempre
usou o argumento do prazo para corrigir erros de programa no banco com
views e triggers (argh!) e o resultado foi: hoje o software está à
beira do caos, lento, inconsistente, insustentável e com o modelo
desorganizado e confuso, ao ponto de uma única regra de negócio
começar no programa, continuar no banco e terminar novamente no
programa. Os limites entre o aplicativo e o SGBD se perderam
completamente.

Não deixe que este tipo de cultura seja criada dentro de uma
organização. Melhor "investir" na correção do aplicativo e arcar com
os custos do novo deploy do que partir para uma solução desse tipo.

___
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] Postgres

[Claudio Bezerra Leopoldino]

Em Quinta-feira, 19 de Dezembro de 2013 15:17, "Guimarães Faria Corcete DUTRA, 
Leandro"  escreveu:

2013/12/19 Leandro 
>
> Nosso servidor não usa nem 30% de sua capacidade, usa o Sistema operacional 
> ubuntu.

Esse número é muito grosseiro.  Como está, por exemplo, a carga em
disco nos momentos críticos?


> Pelos várias situações que conseguimos identificar aqui, está mais próximo de 
> ser o banco.

‘O banco’ também não quer dizer muita coisa.  Um SGBD é um ponto focal
entre vários componentes — memória, rede, discos, CPU, cache,
estruturas de tabelas e índices, consultas, usuários.



> Quando por exemplo há vários usuários fazendo inserções em uma mesma tabela 
> pude notar que a lentidão aumenta mais ainda.

E qual o plano de execução dessas inserções?  Qual a estrutura dessas
tabelas?  Que consultas, com que planos de execução, estão rodando
nesses momentos?

Problemas de concorrência fazem pensar em falta de normalização.



Dependendo da sua necessidade, pode ser necessário:

- Eliminar índices que não estejam sendo utilizados;
- Acrescentar índices em operações que estejam fazendo table scan (use o 
comando explain para descobrir)
- Reorganizar os índices (comando REINDEX). Recomendo que rode um REINDEX 
noturno. Pode ajudar.

O ideal é descobrir que operações e que objetos acessados são as maiores fontes 
de lentidão.

Cordialmente,

Cláudio Leopoldino
postgresqlbr.blogspot.com/___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Postgres

[Claudio Bezerra Leopoldino]

Em Quinta-feira, 19 de Dezembro de 2013 14:42, Leandro  
escreveu:

Boa tarde,

Sou responsável pelo sistema da empresa.

Ultimamente as consultas, inserções e updates no sistema estão muito
lentas.

Temos cerca de 80 usuários online. O vacumm é executado todos os
dias à noite.

Pergunto: Há outras rotinas no postgres para poder melhorar o
desempenho?

Agradeço desde já.

Att,

-- 


 
 

 Leandro Castro  
RD Sistema 
+55 (35) 3473-3550 
www.jfl.com.br   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

=
A execução de ANALYSE pode favorecer o sempenho do seu sistema. 

No entanto, o mais importante é identificar o porquê da lentidão.
- É hardware ou software? É disco? Procesador?
- É o sistema operacional? é o banco de dados?

Para podermos ajudar, você deve dar mais informações.

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] HD lotou no meio de um reindex

[Claudio Bezerra Leopoldino]

 Em 03-12-2013 16:27, Fabio Barros escreveu:

 
>Boa tarde! 
>
>
>Estou postando minha primeira dúvida na lista, e agradeço possíveis 
>comentários.
>
>
>Fiz um REINDEX em uma tabela com cerca de 15 milhões de registros, com cerca 
>de meia dúzia de índices, e como meu disco é pequeno, acabou o espaço no mesmo.
>
>
>Percebi que o tamanho físico do database subiu de 9GB para 15GB, e ao 
>pesquisar, identifiquei vários arquivos perdidos na mesma, que justificam esse 
>crescimento.
>
>
>Acredito que os arquivos se referem aos indices da tabela em questão, e agora 
>preciso 'limpar' esses arquivos do database.
>
>
>Para testes, fizemos um dump/restore e o espaço ocupado fisicamente voltou 
>para os 9GB, mas temos o inconveniente de não poder fazer nada na base de 
>dados enquanto o processo é feito.
>
>
>Posso simplesmente remover os arquivos 'perdidos'?
>
>
>Há outro meio, mais seguro, de se fazer isso?
>
>
>Desde já, agradeço as possíveis sugestões.
>
>
>[]´s
>
>
>Fabio Barros
>
>
>
>
>___
pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 
Olá Fabio.

Como está esta sua tabela?   Está muito fragmentada?
Vc tem visto se o autovacuum está fazendo a reciclagem das tuplas
mortas?
Qual a versão do Postgres que utiliza neste seu banco?
Vc pode usar as functions pg_stat_get_live_tuples(oid) as tpl_vivas
e pg_stat_get_dead_tuples(oid) as tpl_mortas, para verificar qual o
percentual na sua tabela de tuplas mortas.
Seria melhor também dropar os indices que não fazem parte de
constraints e depois recriá-los, ao invés do reindex.
Se a versao do seu banco for um pouco antiga, prefira o CLUSTER ao
inves de VACUUM FULL.

Abraco!

Lucio




-- 
Lucio Chiessi
Rio de Janeiro - Brasil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Amigo, 

Uma solução simples que você pode tentar é excluir os índices e recriá-los! 
Você não vai ter a necessidade de espaço extra para ter ao mesmo tempo o índice 
reindexando e os arquivos temporários.

Cordialmente,

Cláudio___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Check

[Claudio Bezerra Leopoldino]

É possível, sim. Veja este exemplo simples:


CREATE TEMP TABLE noinsert(codigo integer CHECK (codigo <> codigo));

INSERT INTO noinsert values (1); 

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/





Em Terça-feira, 22 de Outubro de 2013 21:12, Eduardo Rodrigues 
 escreveu:
 
Boa noite pessoal,



há alguma maneira de criar um check em uma determinada tabela que impeça de 
realização da instrução insert?



Atenciosamente
Eduardo Rodrigues 


___
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

[pgbr-geral] PgBr Mercosul - Sugestão para Debate...

[Claudio Bezerra Leopoldino]

Boa tarde!

Gostei muito de participar da última PgBr, mas fiquei preocupado com a questão 
do patrocínio. 

Creio que uma possibilidade para facilitar a captação de recursos e a presença 
de palestrantes internacionais seria, ao invés de fazer PgBrs tradicionais, 
realizar uma "PgBr do Mercosul", ou "PgBr Sul-Americana". 

Eventos internacionais são boas formas de divulgação das empresas e podem 
atrair mais atenção de patrocinadores governamentais.

O que acham?

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Tiago Adami 
Para: PGBR  
Enviadas: Terça-feira, 10 de Setembro de 2013 14:12
Assunto: [pgbr-geral] Winsock error 10061
 

Boa tarde colegas.

Sei que a maioria aqui usa Linux (ainda bem!) mas preciso consultá-los
porque com Windows estou tendo um problema relacionado à perda de
conexões frequentes sem motivo aparente com a mensagem de log:

2013-09-09 10:57:52 BRT [2032]: [6537-1] user=postgres,db=frcaixa LOG:
could not receive data from client: unrecognized winsock error 10061
2013-09-09 10:57:52 BRT [2032]: [6538-1] user=postgres,db=frcaixa LOG:
unexpected EOF on client connection
2013-09-09 10:57:52 BRT [2032]:
 [6539-1] user=postgres,db=frcaixa LOG:
disconnection: session time: 2:46:16.156 user=postgres
database=frcaixa host=localhost port=1031

O SGBD continua ativo com os serviços do PostgreSQL em funcionamento
normal. E o pior de tudo: o aplicativo está no "servidor" do banco de
dados, a conexão é feita via driver ODBC padrão do PostgreSQL e
utilizando o endereço "localhost".

Busquei no release notes da versão 9.1.1 até 9.1.9 e não encontrei
nada que possa sugerir uma correção neste aspecto.

Windows XP SP 3 32-bit
PostgreSQL v9.1.4 32-bit

O PostgreSQL é utilizado "embarcado" em uma solução POS para mercados,
infelizmente é um legado e não posso mudar para Linux apesar de querer
muito - antes que uma boa alma sensata sugira esta mudança.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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] PGDay

[Claudio Bezerra Leopoldino]

Bruno, 

Parabenizo pela iniciativa e anexo as lições aprendidas na realização do PgDay 
ceará de 2013:

http://postgresqlbr.blogspot.com.br/2013/05/pgday-ceara-2013-avaliacao-e-licoes.html

Abaixo, links que foram úteis para mim:
Passos para Fazer um PgDay - 
http://wiki.postgresql.org/wiki/Portugu%C3%AAs::PGDayManual
Exemplo de site - http://www.postgresql.org.br/eventos/2012/pgday/sp

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Bruno Silva 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Quinta-feira, 22 de Agosto de 2013 9:28
Assunto: [pgbr-geral] PGDay
 


Sei que não deve ser aqui mas, como faço pra ter informações sobre a execução 
de um PGDay na minha cidade?
Pretendo fazer um aqui em São Luís/MA, então gostaria de ser orientado.



Bruno E. A. Silva.


___
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] Fwd: Funcão para contar dias uteis

[Claudio Bezerra Leopoldino]

Assunto: Re: [pgbr-geral]   Fwd: Funcão para contar dias uteis



>Fabio, desculpa aproveitar da sua bondade, mas como cuido de muita coisa aqui, 
>fica meio dificil assimilar algumas coisas no postgres, sei que para isso 
>seria bom fazer um cursinho, mesmo que rápido em DBA Postgres, mas "sabcome 
>né", então eu lhe pergunto quais as diferenças entre IMMUTABLE, VOLATILE, e 
>STABLE ? 
>Li no manual, mas confeço que fiquei meio confuso, pois ele se refere a dados 
>vindos de tabelas ou não, e ao mesmo tempo cita que os dados podem ser mudados 
>ou não, não compreendi, pois na minha concepção a volatilidade dos dados 
>dependeriam dos dados de entrada também, então o que torna uma função volatil 
>ou não ? Pelo meu ver toda função seria volatil, a menos que se guardasse o 
>resultado em alguma variavel ou tabela, sei lá... 

Veja os exemplos deste post: 

 
http://postgresqlbr.blogspot.com.br/2012/08/categorias-de-volatilidade-de-funcoes.html

Cordialmente,

Cláudio




Em 6 de agosto de 2013 09:36, Fábio Telles Rodriguez  
escreveu:

Em 6 de agosto de 2013 08:56, Marcelo da Silva  escreveu:
>
>> Outro detalhe, relendo seu Post, você está dizendo que é melhor utilizar a
>> verificação em cada select do que ter uma função pra isso? Não entendi.
>
>A regra de ouro é: se dá para fazer com SQL puro, não faça com PL.
>Quando você manda um comando para um SGDB, seja Postgres, SQL Server,
>Oracle, DB2 ou até o Mysql... eles tentam executar o seu comando da
>forma mais eficiente possível. Se você manda uma consulta envolvendo
>varias tabelas, ele vai avaliar em que ordem ele vai pegar as tabelas
>para executar a sua consulta.
>
>Quando você utiliza o PL, o otimizador perde a sua autonomia em favor
>da sua lógica de programação. Claro que se sua função é do tipo
>IMMUTABLE, isso não é tão importante, afinal, você não está
>consultando nenhuma tabela. Mas a sua função vai invariavelmente
>aparecer dentro de um SQL e aí as coisas vão se complicando.
>
>--
>Atenciosamente,
>Fábio Telles Rodriguez
>blog: http://savepoint.blog.br
>e-mail / gtalk / MSN: fabio.tel...@gmail.com
>Skype: fabio_telles
>
>Timbira - A empresa brasileira de Postgres
>http://www.timbira.com.br
>___
>pgbr-geral mailing list
>pgbr-geral@listas.postgresql.org.br
>https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


-- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
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]  Solução para backup

[Claudio Bezerra Leopoldino]

Bom dia!

Se você precisa de menos dados, reduzir o montante de dados armazenados 
excluindo dados antigos é uma boa ideia.

Mas me parece que os mesmos dados continuarão existindo, em outras tabelas, 
para consulta. Neste caso, o ganho será menor. pois não se ganhará espaço em 
disco. Mas haverá ganho pois as consultas aos dados dos últimos meses serão 
mais rápidas. 

Se você não puder apagar todos os dados históricos, tente colocar no histórico 
de dados anteriores a três meses apenas as colunas realmente necessárias, 
eliminando as demais. Reveja também as configurações de log do banco de dados, 
para liberar algum espaço.

Mas se a necessidade é de  hardware mesmo, não dá pra fugir de uma nova 
aquisição de disco, memória e processadores em breve.

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Danilo Silva 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Segunda-feira, 5 de Agosto de 2013 2:06
Assunto: [pgbr-geral]  Solução para backup
 


Pessoal,

O banco cresceu!!! Por falta de recursos de hardware, e a lentidão que está 
atrapalhando algumas rotinas, foi decidido efetuar uma *limpeza*, removendo os 
registros antigos, deixando somente os últimos 3 meses, sendo que o que for 
removido, deverá ficar, de alguma forma, disponível para consulta.

O que é indicado/recomendado para este cenário?


[]s
Danilo
___
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

[pgbr-geral] Tamanho de Campos em Consultas...

[Claudio Bezerra Leopoldino]

Veja o exemplo abaixo: 

EXPLAIN ANALYSE VERBOSE SELECT CAMPO1, CAMPO3 FROM TSTNULL;
Seq Scan on tstnull  (cost=0.00..29.40 rows=1940 width=8) (actual 
time=0.006..0.010 rows=4 loops=1)
  Output: campo1, campo3
Total runtime: 0.033 ms


Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Eduardo Rodrigues 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Quinta-feira, 1 de Agosto de 2013 12:45
Assunto: Re: [pgbr-geral] (sem assunto)
 


Juliano, 

obrigado pela ajuda, mas há algo do tipo quando executar a consulta: "
select * from tbl_tabela where=collumn='';" retornar o espaço que é 
utilizado para armazenar o conteúdo que retornou na consulta??






Em 1 de agosto de 2013 12:27, Juliano Atanazio  
escreveu:


>
>
>
>
>Em 1 de agosto de 2013 12:13, Eduardo Rodrigues  
>escreveu:
>
>Boa tarde pessoal, 
>>
>
>
>Assunto do e-mail?  
>
>>
>>estou dimensionando um novo servidor, e gostaria de saber se há algum recurso 
>>onde eu possa realizar uma consulta e saber qual o tamanho que os dados que 
>>retornar na consulta ocupa no banco de dados?
>>
>
>
># SELECT pg_size_pretty(pg_database_size('nome_da_base')); 
>
>>
>>
>>Atenciosamente
>>Eduardo Rodrigues
>>
>>___
>>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
>
>

___
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] (sem assunto)

[Claudio Bezerra Leopoldino]

Meu caro, o comando EXPLAIN ANALYSE ; supre essa necessidade.

Você pode usar também EXPLAIN ANALYZE VERBOSE  ;


Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Eduardo Rodrigues 
Para: pgbr-geral  
Enviadas: Quinta-feira, 1 de Agosto de 2013 12:13
Assunto: [pgbr-geral] (sem assunto)
 


Boa tarde pessoal, 


estou dimensionando um novo servidor, e gostaria de saber se há algum recurso 
onde eu possa realizar uma consulta e saber qual o tamanho que os dados que 
retornar na consulta ocupa no banco de dados?



Atenciosamente
Eduardo Rodrigues

___
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] Permissões e Restrições de acesso a banco

[Claudio Bezerra Leopoldino]

Altere a senha do grupo e não a dê para os outros. 

Crie novo grupo e dê permissão apenas de leitura nas tabelas e distribua a 
senha para os usuários. Abaixo, um post relacionado:
http://postgresqlbr.blogspot.com.br/2012/07/gere-automaticamente-seus-comandos.html

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Paulo Bastos 
Para: pgbr-geral@listas.postgresql.org.br 
Enviadas: Quinta-feira, 11 de Julho de 2013 9:26
Assunto: [pgbr-geral] Permissões e Restrições de acesso a banco
 


 
Desculpem,
 
enviei o email anterior e esqueci de colocar o assunto.
 
Senhores(as),
 
Em um servidor tenho vários bancos dentro de um unico cluster. Como proceder
para fazer que os objetos do banco só possam ser consultados?
 
Todas as tabelas estão associadas a um unico grupo.
 
Antecipadamente agradeço a ajuda.
 
Paulo Bastos
___
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] Duvida básica LEFT JOIN x NOT IN

[Claudio Bezerra Leopoldino]

Marcelo, a diferença de custos entre as duas opções não é tão significativa. 

Os planos de execução mostram que você está fazendo sequential scans. Neste 
caso, aconselho que tente indexar as colunas utilizadas nas junções e teste se 
há melhoria na sua consulta e depois disso peço que repita o teste do explain.

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Marcelo da Silva 
Para: Claudio Bezerra Leopoldino ; Comunidade 
PostgreSQL Brasileira  
Enviadas: Sexta-feira, 5 de Julho de 2013 14:54
Assunto: Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN
 


Tempo os seguintes resultados:

OPCAO A


explain select a.* from mv_servicos_balcao a
left join mv_servicos_print b on(cod_key_balcao = a.cod_key)
where (b.cod_key is null)
  and(a.obs not in('C'));

"Hash Right Join  (cost=9510.11..17269.55 rows=1 width=136)"
"  Hash Cond: (b.cod_key_balcao = a.cod_key)"
"  Filter: (b.cod_key IS NULL)"
"  ->  Seq Scan on mv_servicos_print b  (cost=0.00..3746.55 rows=213355 
width=8)"
"  ->  Hash  (cost=7913.20..7913.20 rows=127753 width=136)"
"        ->  Seq Scan on mv_servicos_balcao a  (cost=0.00..7913.20 rows=127753 
width=136)"
"              Filter: (obs <> 'C'::bpchar)"


OPCAO B

explain select a.* from mv_servicos_balcao a
where (a.obs not in('C'))
  and(a.cod_key not in(select cod_key_balcao from mv_servicos_print))

"Seq Scan on mv_servicos_balcao a  (cost=4279.94..12516.98 rows=63876 
width=136)"
"  Filter: ((obs <> 'C'::bpchar) AND (NOT (hashed SubPlan 1)))"
"  SubPlan 1"
"    ->  Seq Scan on mv_servicos_print  (cost=0.00..3746.55 rows=213355 
width=4)"


Vou ser sincero... não sei fazer a leitura do explain, mas pelo que vi a 
segunda opção se mostrou mais eficiente, haja visto que sem o explain temos os 
seguintes valores em ms(milisegundos)

OPCAO A = 571 rows e 496ms
OPCAO B = 571 rows e 300ms

Mito detonado ? rsrsrs




Em 5 de julho de 2013 14:31, Claudio Bezerra Leopoldino 
 escreveu:

Não depende apenas da consulta. Depende dos dados armazenados e estatísticas no 
seu servidor.
>
>Peço que use explain e noso envie o reultado:
>
>
>EXPLAIN SELECT A.CAMPOS FROM TABELA_A A
>LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
>WHERE (B.CAMPO IS NULL)
>
>
>e
>
>
>EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A
>
>
>WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))
>
>
>Cordialmente,
>
>
>Cláudio Leopoldino
>postgresqlbr.blogspot.com/
>=
>
>
>
> De: Marcelo da Silva 
>Para: Comunidade PostgreSQL Brasileira  
>Enviadas: Sexta-feira, 5 de Julho de 2013 14:25
>Assunto: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN
> 
>
>
>Qual seria o mais eficiente ?
>
>
>SELECT A.CAMPOS FROM TABELA_A A
>LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
>WHERE (B.CAMPO IS NULL)
>
>
>ou
>
>
>SELECT A.CAMPOS FROM TABEL_A A
>
>WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))
>
>
>
>-- 
>
>Marcelo Silva
>
>Desenvolvedor Delphi / PHP
>My Postgres database
>Cel.: (11) 99693-4251
>
>___
>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
>
>


-- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN

[Claudio Bezerra Leopoldino]

Não depende apenas da consulta. Depende dos dados armazenados e estatísticas no 
seu servidor.

Peço que use explain e noso envie o reultado:


EXPLAIN SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)

e

EXPLAIN  SELECT A.CAMPOS FROM TABEL_A A

WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))

Cordialmente,


Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Marcelo da Silva 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Sexta-feira, 5 de Julho de 2013 14:25
Assunto: [pgbr-geral] Duvida básica LEFT JOIN x NOT IN
 


Qual seria o mais eficiente ?

SELECT A.CAMPOS FROM TABELA_A A
LEFT JOIN TABELA_B B ON(B.CODIGO = A.CODIGO)
WHERE (B.CAMPO IS NULL)

ou

SELECT A.CAMPOS FROM TABEL_A A

WHERE (A.CODIGO NOT IN(SELECT CODIGO FROM TABELA_B))

-- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
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] Extrair Mês e Ano de um campo Date para Relatório no iReport

[Claudio Bezerra Leopoldino]

Utilize a função to_char, como no exemplo abaixo. Use || para fazer as 
concatenações de string.

SELECT TO_CHAR(current_date, 'DD') AS DIA, TO_CHAR(current_date, 'MM') AS MES, 
TO_CHAR(current_date, '') AS ANO;

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Ramiro Pamponet 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Terça-feira, 18 de Junho de 2013 12:03
Assunto: [pgbr-geral] Extrair Mês e Ano de um campo Date para Relatório no 
iReport
 


Boa tarde Pessoal,

tenho a seguinte query abaixo ...

select distinct unidade, estado, extract(year from data) as ano, extract(month 
from data) as mes, sum(vendas) as atendimentos from(
select distinct nom_filial as unidade, est_filial as estado, (dat_emissao) as 
data, count(dat_emissao) as vendas 
from cadcvend, cadfilia
where cadfilia.cod_filial = cadcvend.cod_filial
and flg_excluido is null 
and num_nf is null
and extract(year from dat_emissao) between 2004 and 2013
and extract(month from dat_emissao) between 1 and 12
group by dat_emissao, nom_filial, est_filial order by dat_emissao) as registro
where extract(year from data) between 2004 and 2013
and extract(month from data) between 1 and 12
group by extract(year from data), extract(month from data), unidade, estado
order by extract(year from data), extract(month from data)

que está funcionando, mas não do jeito que eu queria. O que eu realmente queria 
era um único campo contendo o mês e o ano. Será que isso é possível?

___
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] Ordem da Chave Primária

[Claudio Bezerra Leopoldino]

Para relatórios que precisem apenas do campo ID_EMPRESA, crie um índice apenas 
sobre este campo. A mesma recomendação se aplica aos relatórios com consulta 
sobre o campo ID_VENDA.

Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Fábio Thomaz 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Sexta-feira, 14 de Junho de 2013 13:40
Assunto: Re: [pgbr-geral] Ordem da Chave Primária
 


Então talvez seria mais interessante eu sempre primeiramente ter o ID_EMPRESA 
neste caso né? Já que em alguns relatórios eu irei filtrar apenas por este 
campo alguns outros dependendo da situação.



Em 14 de junho de 2013 13:31, Alessandro Gonçalves  escreveu:

Olá Fábio.
>
>
>Sim existe sim, isso ajuda na filtragem.
>
>
>Existe uma ordem onde é analisado os campos da esquerda para direita.
>
>
>
>
>Em 14 de junho de 2013 13:27, Fábio Thomaz  escreveu:
>
>Olá pessoal!
>>
>>
>>   Gostaria de saber dos expert's em BD se existe alguma diferença em usar 
>>primeiro um campo ou outro em uma chave primária composta.
>>
>>
>>Ex:
>>
>>
>>Tabela: Vendas
>>PK: ID_EMPRESA, ID_VENDA ou ID_VENDA, ID_EMPRESA
>>
>>
>>  Isto faz alguma diferença? Sei que faz diferença quando uso uma consulta 
>>SQL caso eu crie a clausula where fora desta ordem, mas com relação aos dados 
>>que ai serão gravados, de uma forma ficaria mais otimizado que de outra?
>>
>>
>>Att,
>>Fábio Thomaz
>>___
>>pgbr-geral mailing list
>>pgbr-geral@listas.postgresql.org.br
>>https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
>-- 
>
>   Alessandro Gonçalves
>Programador de Sistemas para Web
>
>___
>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___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Claudio Bezerra Leopoldino]

Bom dia, Alessandro!

Coloco algumas ideias 

Se você deseja uma replicação síncrona, utilizar um segundo servidor de 
qualidade inferior vai degradar a performance do sistema como um todo.


O hd externo geralmente não apresenta um bom desempenho para operações com 
grande quantidade de dados. Se precisares, utilize ao menos USB 3.0. Mas não 
recomendo. Você pode cogitar uma ferramenta de backup e recovery com compressão 
de dados como: pgbarman (http://www.pgbarman.org/) e pg-rman 
(http://code.google.com/p/pg-rman/).


O backup é muito útil quando se deseja recuperar um estado anterior do banco. E 
como não podemos antever esta necessidade, a replicação não tem como eliminar 
totalmente a necessidade de backup.

Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Alessandro Lima 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Quarta-feira, 12 de Junho de 2013 9:10
Assunto: [pgbr-geral] (sem assunto)
 


Bom dia a todos, gostaria de algumas dicas (boas praticas), sobre backup, 
replicação, etc...

obs.: Utilizarei postgres 9.2, debian 7, servidor dell (ainda em fase de 
cotação)

Minha idéia inicial seria:

RAID 1 ( 2 x 600GB SAS 15k - servidor dell t4200)
Replicação (MASTER - servidor dell, SLAVE - servidor usado ibm)

Backup online

Backup em hd externo
Backup remoto nos estados unidos

Dúvidas: 
1- Nunca fiz replicação no postgres, o slave pode ser um computador inferior 
com sata, não interfere na performance do master com sas?
2 - a replicação substitui a necessidade do backup online?
3 - o que é recomendado armazenar em hd externo ou servidor remoto, uma cópia 
da pasta data, um pg_dump, uma cópia do backup online?



Alessandro Lima
email grandegoia...@gmail.com

___
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] Armazenar ou não imagens

[Claudio Bezerra Leopoldino]

Bruno, ao armazenar imagens no SGBD, você está acrescentando mais uma camada 
para o acesso às mesmas, com implicações negativas para o desempenho.

Adicionalmente, o filesystem é otimizado para acesso a arquivos como os das as 
imagens que você deseja armazenar. O SGBD visa organizar e otimizar o acesso a 
dados. 

A meu ver você deveria se perguntar que filesystem utilizar, e não se vale a 
pena armazenar no BD.

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Bruno Silva 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Quarta-feira, 29 de Maio de 2013 14:44
Assunto: [pgbr-geral] Armazenar ou não imagens
 


Boa tarde pessoal, estava com umas dúvidas em relação a guardar imagem no banco 
de dados. E nos posts que pesquisei na lista, a meu ver, ficou balanceado. Mas 
eram posts antigos.
Fiz uns testes numa época no Postgres e achei a performance boa.
Agora tenho uma demanda que de inicio me terá mais de 40 só de imagens. No lado 
da programação será mais fácil armazenar no banco, pois não terei de ficar 
fazendo o mesmo ler de banco e depois ler do FS.
Então queria entender, qual o explicação técnica de não se armazenar a imagem, 
ou Large Objects,  no PostgreSQL, ou qualquer outro banco de dados ?

Obs.: Essa base será para um site.


Bruno E. A. Silva.
Analista de Sistemas.

___
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] Mostrar valor variável ambiente

[Claudio Bezerra Leopoldino]

Tente:

SHOW SEARCH_PATH;

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Pedro B. Alves 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Segunda-feira, 27 de Maio de 2013 14:48
Assunto: [pgbr-geral] Mostrar valor variável ambiente
 


Pessoal tem como eu visualizar os valores das variáveis de ambiente através de 
comando?

Ex:
Set search_patch = banco;

Como visualizar a variável search_patch
___
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] Client Postgres, será possível?

[Claudio Bezerra Leopoldino]

Amigo, o Squirel Client é uma boa opção e você só precisa do driver JDBC. Ele 
funciona com o postgres e com outros bancos de dados. 

http://squirrel-sql.sourceforge.net/

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Marcelo da Silva 
Para: Comunidade PostgreSQL Brasileira  
Enviadas: Quarta-feira, 22 de Maio de 2013 8:30
Assunto: [pgbr-geral] Client Postgres, será possível?
 




Pessoal, uma coisa que tenho notado é que os desenvolvedores que migram para o 
Postgres tem dificuldade de rodar um Client por causa das DLLs que devem ir 
junto.
Depois de apanhar um pouco acabei por aprender, mas gostaria de deixar uma 
sugestão, vai que alguém da lista tem acesso ao pessoal do desenvolvimento.

No firebird tem a opção de instalação do Client sem o Server, assim ele instala 
as dependências para que a aplicação possa rodar sem problemas.

Será que o pessoal do Postgres não poderia fazer isso?

Tem muita gente deixando outras bases no Delphi e migrando para o Postgres, mas 
estão tendo dificuldade na instalação em maquinas sem nada do postgres.

Eles até levam as DLLs usadas no desenvolvimento, mas o VisualC++ exige outras 
DLLs que só são instaladas com a instalação do Server.
 -- 

Marcelo Silva

Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
___
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

[pgbr-geral] Registro do PgDay Ceará 2013...

[Claudio Bezerra Leopoldino]

Gente, boa tarde!


Qual é o procedimento para atualizar o site da comunidade? 


Não estou conseguindo acrescentar o registro da frelização do PgDay Ceará 2013.

Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral