Re: [pgbr-geral] init.d inicializando o postgres automaticamente

2009-09-24 Por tôpico Tarcísio Sassara
Pronto, pronto.
Segui os passos contidos no próprio arquivo do contrib.

Mas lendo o arquivo por inteiro, abaixo da linha STOP EDITING HERE o
script faz uma coisa estranha.
Eu achava que era sempre correto inicializar e parar o postgres com o
pg_ctl. Porem:

# What to use to start up the postmaster (we do NOT use pg_ctl for this,
# as it adds no value and can cause the postmaster to misrecognize a stale
# lock file)
DAEMON=$prefix/bin/postmaster

Não sabia deste problema mas encontrei uma thread interessante na lista, uma
boa discussão entre o Tom Lane, Josh Berkus e outros.
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php

De qualquer maneira, devemos (se for o caso) utilizar o start-script do
contrib mesmo.



2009/9/23 Joao Cosme de Oliveira Junior joao.co...@serpro.gov.br

 vai no contrib start-scripts la no source e copia pro seu init.d
 modificando o seu pgdata  no arquivo


 Em 23/09/2009 às 21:14 horas, pgbr-ge...@listas.postgresql.org.brescreveu:

  Tarcísio Sassara escreveu:

 Olá pessoal.
  Motivação:
 Uma das coisas que já resolvi é não utilizar o pacote de instalação do
 debian para a próxima aplicação.
 Minha preocupação é a de sempre manter o banco rodando sempre na ultima
 versão corrente.
 Fiz alguns testes para a migração da minha base da versão 8.3 para a 8.4
 rodando a
 versão antiga simultâneamente mudando a porta de comunicação e tudo ocorreu
 muito bem.

  O problema:
  Minha duvida é como configurar o serviço para inicializar e parar
 automaticamente com o SO usando o
 init.d que é um dos padrões do debian para esta tarefa. Gostaria de chamar
 o pg_ctl start e stop no momento correto.

  Tentei aprender algo com a maneira que o pacote do postgres no debian faz
 mas é meio doido.

  Se alguém puder me ajudar, ou tiver um material legal sobre o assunto vou
 agradecer bastante.
 Dei uma pesquisada sobre o init.d mas de qualquer maneira, gostaria de mais
 informações relacionadas ao postgres.

  Valeu!

 --
 Tarcisio F. Sassara

 --

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



 Boa noite Tarcísio.

 Há algum tempo tive o mesmo problema, abaixo uma descrição rápida da
 solução que encontrei:


 Iniciando o servidor de banco de dados PostgreSQL no boot do Debian
 Script para postgres como serviço e iniciar tal serviço no boot do Debian

 #!/bin/sh
 # pg_script
 # Controla start / stop do Postgresql

 case $1 in
 start) echo -n Iniciando servico do PostgreSQL;
 /bin/su - postgres -c /usr/local/pgsql/bin/pg_ctl start -D
 /usr/local/pgsql/data  logfile 21
 ;;
 stop) echo -n Parando serviço do PostgreSQL;
 /bin/su - postgres -c /usr/local/pgsql/bin/pg_ctl stop -D
 /usr/local/pgsql/data  logfile 21
 ;;
 restart) echo -n Reiniciando serviço PostgreSQL;
 /bin/su - postgres -c /usr/local/pgsql/bin/pg_ctl restart -D
 /usr/local/pgsql/data  logfile 21
 ;;
 esac
 exit 0

 Link simbólico para executar o script na runlevel 2

 cd /etc/rc2.d
 ln -s ../init.d/pg_script S50pg_script
 telinit rc2.d

 Saída do comando 'netstat -tuapen'

 Conexões Internet Ativas (servidores e estabelecidas)
 Proto Recv-Q Send-Q Endereço Local  Endereço Remoto
 Estado  User   Inode   PID/Program name
 tcp0  0 0.0.0.0:111 0.0.0.0:*
 OUÇA   0  42251502/portmap
 tcp0  0 0.0.0.0:34256   0.0.0.0:*
 OUÇA   0  42951513/rpc.statd
 tcp0  0 0.0.0.0:113 0.0.0.0:*
 OUÇA   0  53772225/inetd
 tcp0  0 0.0.0.0:22  0.0.0.0:*
 OUÇA   0  50081907/sshd
 tcp0  0 127.0.0.1:631   0.0.0.0:*
 OUÇA   0  50741934/cupsd
 *tcp0  0 127.0.0.1:5432  0.0.0.0:*
 OUÇA   1001   64772380/postgres  *
 tcp0  0 127.0.0.1:250.0.0.0:*
 OUÇA   0  52742201/exim4
 tcp0  0 127.0.0.1:6010  0.0.0.0:*
 OUÇA   1000   81202721/0
 tcp0160 192.168.0.244:2210.200.110.54:50489
 ESTABELECIDA 0  80822717/sshd: leandro
 tcp6   0  0 :::22   :::*
 OUÇA   0  50061907/sshd
 tcp6   0  0 ::1:631 :::*
 OUÇA   0  50751934/cupsd
 *tcp6   0  0 ::1:5432:::*
 OUÇA   1001   64782380/postgres   *
 tcp6   0  0 ::1:6010:::*
 OUÇA   1000   81212721/0
 udp0  0 0.0.0.0:68  0.0.0.0:*
 0  61162336/dhclient
 udp0  0 0.0.0.0:50629   0.0.0.0:*
 10549791895/avahi-daemon:
 udp0  0 0.0.0.0:841 0.0.0.0:*
 0  4281 

Re: [pgbr-geral] Memory (heap)

2009-09-24 Por tôpico Tarcísio Sassara
Bom dia pra todos.

Acompanhando as mensagens de perto, achei o assunto interessante e resolvi
brincar um pouco.
Mas antes, minha opinião:

Se só quero usar o SGBD para armazenar dados temporários com direito a
acesso muito rápido, talvez seja melhor usar outra abordagem que não
empregue o postgres.
Mas e se for o caso da aplicação a ser desenvolvida já faz uso do postgres?
Se já tenho o banco rodando, mas tenho uma tabelinha sem vergonha que uso
para armazenar algo descartável e que é mais importante um acesso rápido,
eu, de primeira,
pensaria em criar o tablespace temporário e engoliria o WAL, ou seja, vai ir
para o WAL mas tudo bem. OK? Bom fiz alguns testes e não foi muito legal o
resultado para esta abordagem.

Fui para a maquina virtual fazer alguns benchmarks bem por cima.

1º teste: instalação padrão.
2º teste: instalação com todo o cluster e binários em um fs temporário.
3º teste: instalação padrão com um tablespace temporário.

Comandos do pgbench utilizados

# inicializa as tabelas usadas pelo pgbench com um scale factor igual a 10
no banco de dados postgres
pgbench -i -s 10 postgres

# roda o proprio benchmark com 10 conexões simultaneas 1000 vezes para cada
uma destas.
pgbench -c 10 -t 1000 postgres


1º teste: Instalação padrão. Resultado:

 tps = 477.656061 (including connections establishing)
 tps = 478.578011 (excluding connections establishing)
---

2º teste: Instalação com todo o cluster e binarios em um fs temporario:

montei um tmpfs seguindo o comando de um dos links fornecidos pelo Fabrízio.
Aumentei o tamanho do fs para conseguir rodar o pgbench:

$ sudo mount -t tmpfs -o size=500M,uid=tarcisio,gid=tarcisio,mode=0700 tmpfs
/home/tarcisio/tmpfs
configurei e instalei o postgres junto com o contrib tudo ai dentro.
Rodei o pgbench:

 tps = 823.146755 (including connections establishing)
 tps = 825.540711 (excluding connections establishing)

Quase o dobro. Porem, não vejo utilidade/praticidade em colocar o cluster
inteiro junto com os binários do postgres dentro de um fs temporário.
Se o que quero é algo bem simples e minha aplicação não utilizará o postgres
pra nada alem disso, prefiro estudar outras ferramentas.

---

3º teste: Instalação padrão com um tablespace temporário.

Matei a instalação anterior. sudo umount /home/tarcisio/tmpfs
Montei de novo com tudo limpo e criei o tablespace:
=# CREATE TABLESPACE tmpfs OWNER tarcisio LOCATION '/home/tarcisio/tmpfs';

ALTEREI o código fonte do pgbench para criar as tabelas e indices dentro do
tablespace
Disso: create table tabela_aqui
Fiz isso: create table tabela_aqui TABLESPACE tmpfs
E disso: alter table pgbench_*** add primary key (bid)
Fiz isso: alter table pgbench_*** add primary key (bid) USING INDEX
TABLESPACE tmpfs
Compilei o pgbench de novo e rodei:

 tps = 453.644599 (including connections establishing)
 tps = 454.687999 (excluding connections establishing)

Foi pior que a instalação padrão! Ou seja, talvez não seja uma boa opção.
(ou benchmark mau feito)
Se já uso o postgres no cotidiano da minha aplicação, não tentaria inventar
moda.
Criaria a tabela normalmente e ficaria agradecido pela velocidade que fosse.
(isso é uma meia-verdade)

O postgres não é lento para consultas em uma única tabela pequena como a que
pensaríamos em colocar na memória.
A coisa só começa a ficar feia com consultas complexas envolvendo joins e
cálculos. O que vale para outros SGBDS.



2009/9/24 Fabrízio de Royes Mello fabriziome...@gmail.com



 2009/9/23 Euler Taveira de Oliveira eu...@timbira.com

 Dois comentários: (i) se você preza pelos seus dados *não* faça isso a não
 ser
 que os mesmos sejam dados de sessão e (ii) mesmo que você crie uma
 tablespace
 e coloque a sua tabela lá, os dados vão precisar ser escritos no WAL então
 _nem_ tudo vai ser escrito em memória.


 Com certeza, mas em se tratando de dados voláteis não teriamos problemas
 não é mesmo... e no caso do WAL o artigo que indiquei consta um comentário
 do Sr. Pavel Stehule que fala justamente sobre a escrita no WAL então seria
 interessante ter o cluster inteiro na ramfs para ter tudo em memória...



 Quanto a dúvida do OP, o PostgreSQL *não* possui um equivalente ao
 _engine_
 memory. Apesar disso, se essa tabela é utilizada com certa frequência e
 você
 possui uma configuração adequada de _shared buffers_, com certeza, esta
 tabela
 estará na memória.


 No comentário ele também fala que o mais correto seria ajustar o valor do
 shared buffers... mas tendo um valor adequado nesse parâmetro mesmo assim
 teremos I/O do WAL certo? Então se a necessidade é escrever dados em memória
 em função do desempenho de I/O então o cluster inteiro na RAM seria
 inevitável... e pra manter isso somente com dados voláteis mesmo... (que
 baita *gambiarra* isso me parece)


 O amigo Everson poderia dar mais detalhes da sua real necessidade, porque
 daqui a pouco não é com o PostgreSQL que ele vai encontrar a solução. Há
 algum tempo li o artigo Database Overkill do Sr. 

Re: [pgbr-geral] Campo Calculado

2009-09-24 Por tôpico B i l l
Obrigado Osvaldo!


2009/9/23 Osvaldo Kussama osvaldo.kuss...@gmail.com

 2009/9/23 B   i   l   l uellinton.amo...@gmail.com:


 Crie uma view.
 Direto na tabela não tem sentido, vide regras de normalização.

 Osvaldo
 ___
 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] backup windows

2009-09-24 Por tôpico Ralf Schlindwein
@Echo Iniciando processo de backup ...

for /f tokens=1,2,3,4 delims=/  %%a in ('DATE /T') do set Date=%%b-%%c-%%d
pg_dump.exe -i -h localhost -d *banco* -p 5432 -U postgres -f
C:\%Date%.backup

@Echo Fim do processo de backup


Porem meu banco tem senha e quando eu executo a .bat fica pedindo password
como eu implemento a senha automatica na .bat ?
___
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 windows

2009-09-24 Por tôpico Fabrízio de Royes Mello
2009/9/24 Ralf Schlindwein ralfoa...@gmail.com

 @Echo Iniciando processo de backup ...

 for /f tokens=1,2,3,4 delims=/  %%a in ('DATE /T') do set
 Date=%%b-%%c-%%d
 pg_dump.exe -i -h localhost -d *banco* -p 5432 -U postgres -f
 C:\%Date%.backup

 @Echo Fim do processo de backup


 Porem meu banco tem senha e quando eu executo a .bat fica pedindo password
 como eu implemento a senha automatica na .bat ?


Dê uma olhada em [1] e qualquer dúvida nos envie.

[1] http://www.postgresql.org/docs/current/static/libpq-pgpass.html

-- 
Fabrízio de Royes Mello
 Blog sobre TI: http://fabriziomello.blogspot.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Res: Memory (heap)

2009-09-24 Por tôpico MARCIO CASTRO
Caro Tarcísio:

  Achei muito interessante o seu teste, porém, você pode ter pecado na frase O 
que vale para outros SGBDS. O que eu tenho observado é que o Postgres é 
extremamente lento em DETERMINADAS situações, comparado ao SGBD Oracle, por 
exemplo.
  Há alguns dias atrás, postei um exemplo de uma função em PL/pgSQL que 
simplesmente realizava um loop, onde a cada interação, era somado +1 para uma 
variável. Fiz o mesmo no Oracle (11g), numa instalação de testes em um Celeron, 
e foi muito mais rápido!
  Na época, cheguei até a pensar que existia um problema no servidor, no Linux 
ou na instalação do PostgreSQL. Também não sei se este problema é específico do 
PL/pgSQL ou do PostgreSQL, mas o fato é que também ainda não achei nenhuma 
explicação para o ocorrido.


Atenciosamente,

Márcio de Figueiredo Moura e Castro







De: Tarcísio Sassara sassara.tarci...@gmail.com
Para: fabriziome...@gmail.com; Comunidade PostgreSQL Brasileira 
pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 24 de Setembro de 2009 6:28:09
Assunto: Re: [pgbr-geral] Memory (heap)

Bom dia pra todos.

Acompanhando as mensagens de perto, achei o assunto interessante e resolvi 
brincar um pouco.
Mas antes, minha opinião:

Se só quero usar o SGBD para armazenar dados temporários com direito a acesso 
muito rápido, talvez seja melhor usar outra abordagem que não empregue o 
postgres.
Mas e se for o caso da aplicação a ser desenvolvida já faz uso do postgres?
Se já tenho o banco rodando, mas tenho uma tabelinha sem vergonha que uso 
para armazenar algo descartável e que é mais importante um acesso rápido, eu, 
de primeira,
pensaria em criar o tablespace temporário e engoliria o WAL, ou seja, vai ir 
para o WAL mas tudo bem. OK? Bom fiz alguns testes e não foi muito legal o 
resultado para esta abordagem.

Fui para a maquina virtual fazer alguns benchmarks bem por cima.

1º teste: instalação padrão.
2º teste: instalação com todo o cluster e binários em um fs temporário.
3º teste: instalação padrão com um tablespace temporário.

Comandos do pgbench utilizados

# inicializa as tabelas usadas pelo pgbench com um scale factor igual a 10 no 
banco de dados postgres
pgbench -i -s 10 postgres

# roda o proprio benchmark com 10 conexões simultaneas 1000 vezes para cada uma 
destas.
pgbench -c 10 -t 1000 postgres


1º teste: Instalação padrão. Resultado:

 tps = 477.656061 (including connections establishing)
 tps = 478.578011 (excluding connections establishing)
---

2º teste: Instalação com todo o cluster e binarios em um fs temporario:

montei um tmpfs seguindo o comando de um dos links fornecidos pelo Fabrízio.
Aumentei o tamanho do fs para conseguir rodar o pgbench:

$ sudo mount -t tmpfs -o size=500M,uid=tarcisio,gid=tarcisio,mode=0700 tmpfs 
/home/tarcisio/tmpfs
configurei e instalei o postgres junto com o contrib tudo ai dentro.
Rodei o pgbench:

 tps = 823.146755 (including connections establishing)
 tps = 825.540711 (excluding connections establishing)

Quase o dobro. Porem, não vejo utilidade/praticidade em colocar o cluster 
inteiro junto com os binários do postgres dentro de um fs temporário.
Se o que quero é algo bem simples e minha aplicação não utilizará o postgres 
pra nada alem disso, prefiro estudar outras ferramentas.

---

3º teste: Instalação padrão com um tablespace temporário.

Matei a instalação anterior. sudo umount /home/tarcisio/tmpfs
Montei de novo com tudo limpo e criei o tablespace:
=# CREATE TABLESPACE tmpfs OWNER tarcisio LOCATION '/home/tarcisio/tmpfs';

ALTEREI o código fonte do pgbench para criar as tabelas e indices dentro do 
tablespace
Disso: create table tabela_aqui
Fiz isso: create table tabela_aqui TABLESPACE tmpfs
E disso: alter table pgbench_*** add primary key (bid)
Fiz isso: alter table pgbench_*** add primary key (bid) USING INDEX TABLESPACE 
tmpfs
Compilei o pgbench de novo e rodei:

 tps = 453.644599 (including connections establishing)
 tps = 454.687999 (excluding connections establishing)

Foi pior que a instalação padrão! Ou seja, talvez não seja uma boa opção. (ou 
benchmark mau feito)
Se já uso o postgres no cotidiano da minha aplicação, não tentaria inventar 
moda.
Criaria a tabela normalmente e ficaria agradecido pela velocidade que fosse. 
(isso é uma meia-verdade)

O postgres não é lento para consultas em uma única tabela pequena como a que 
pensaríamos em colocar na memória.
A coisa só começa a ficar feia com consultas complexas envolvendo joins e 
cálculos. O que vale para outros SGBDS.




2009/9/24 Fabrízio de Royes Mello fabriziome...@gmail.com




2009/9/23 Euler Taveira de Oliveira eu...@timbira.com


Dois comentários: (i) se você preza pelos seus dados *não* faça isso a não 
ser
que os mesmos sejam dados de sessão e (ii) mesmo que você crie uma 
tablespace
e coloque a sua tabela lá, os dados vão precisar ser escritos no WAL então
_nem_ tudo vai ser escrito em memória.



Com certeza, mas em se tratando de 

Re: [pgbr-geral] Res: Memory (heap)

2009-09-24 Por tôpico Tarcísio Sassara
Ah, então Márcio, eu cheguei a acompanhar o seu problema. E eu ia responder
como outra pessoa aqui da lista que era possível utilizar outras linguagens
para resolver seu problema, mas você acabou com qualquer chances de resposta
dizendo que não queria alterar seu arquivo sql contendo a estrutura e as
funções do seu banco. ;-)
Porque tenho quase certeza de que se eu criasse uma versão em C do
fibonacci, o postgres acabaria com o pl do oracle. Yaaah!

Brincadeiras de lado... Você está certo.
Ocorre que: Em alguns momentos devemos usar métodos diferentes para resolver
problemas semelhantes em SGBDs diferentes. E isso é de se esperar. Não é
verdade?
Vale o mesmo quando comparado o SQL Server e Oracle.


Valeu!




2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br

  Caro Tarcísio:

   Achei muito interessante o seu teste, porém, você pode ter pecado na
 frase O que vale para outros SGBDS. O que eu tenho observado é que o
 Postgres é extremamente lento em DETERMINADAS situações, comparado ao SGBD
 Oracle, por exemplo.
   Há alguns dias atrás, postei um exemplo de uma função em PL/pgSQL que
 simplesmente realizava um loop, onde a cada interação, era somado +1 para
 uma variável. Fiz o mesmo no Oracle (11g), numa instalação de testes em um
 Celeron, e foi muito mais rápido!
   Na época, cheguei até a pensar que existia um problema no servidor, no
 Linux ou na instalação do PostgreSQL. Também não sei se este problema é
 específico do PL/pgSQL ou do PostgreSQL, mas o fato é que também ainda não
 achei nenhuma explicação para o ocorrido.


 Atenciosamente,

 Márcio de Figueiredo Moura e Castro



 --
 *De:* Tarcísio Sassara sassara.tarci...@gmail.com
 *Para:* fabriziome...@gmail.com; Comunidade PostgreSQL Brasileira 
 pgbr-geral@listas.postgresql.org.br
 *Enviadas:* Quinta-feira, 24 de Setembro de 2009 6:28:09
 *Assunto:* Re: [pgbr-geral] Memory (heap)

 Bom dia pra todos.

 Acompanhando as mensagens de perto, achei o assunto interessante e resolvi
 brincar um pouco.
 Mas antes, minha opinião:

 Se só quero usar o SGBD para armazenar dados temporários com direito a
 acesso muito rápido, talvez seja melhor usar outra abordagem que não
 empregue o postgres.
 Mas e se for o caso da aplicação a ser desenvolvida já faz uso do postgres?
 Se já tenho o banco rodando, mas tenho uma tabelinha sem vergonha que uso
 para armazenar algo descartável e que é mais importante um acesso rápido,
 eu, de primeira,
 pensaria em criar o tablespace temporário e engoliria o WAL, ou seja, vai
 ir para o WAL mas tudo bem. OK? Bom fiz alguns testes e não foi muito legal
 o resultado para esta abordagem.

 Fui para a maquina virtual fazer alguns benchmarks bem por cima.

 1º teste: instalação padrão.
 2º teste: instalação com todo o cluster e binários em um fs temporário.
 3º teste: instalação padrão com um tablespace temporário.

 Comandos do pgbench utilizados

 # inicializa as tabelas usadas pelo pgbench com um scale factor igual a
 10 no banco de dados postgres
 pgbench -i -s 10 postgres

 # roda o proprio benchmark com 10 conexões simultaneas 1000 vezes para cada
 uma destas.
 pgbench -c 10 -t 1000 postgres


 1º teste: Instalação padrão. Resultado:

  tps = 477.656061 (including connections establishing)
  tps = 478.578011 (excluding connections establishing)
 ---

 2º teste: Instalação com todo o cluster e binarios em um fs temporario:

 montei um tmpfs seguindo o comando de um dos links fornecidos pelo
 Fabrízio.
 Aumentei o tamanho do fs para conseguir rodar o pgbench:

 $ sudo mount -t tmpfs -o size=500M,uid=tarcisio,gid=tarcisio,mode=0700
 tmpfs /home/tarcisio/tmpfs
 configurei e instalei o postgres junto com o contrib tudo ai dentro.
 Rodei o pgbench:

  tps = 823.146755 (including connections establishing)
  tps = 825.540711 (excluding connections establishing)

 Quase o dobro. Porem, não vejo utilidade/praticidade em colocar o cluster
 inteiro junto com os binários do postgres dentro de um fs temporário.
 Se o que quero é algo bem simples e minha aplicação não utilizará o
 postgres pra nada alem disso, prefiro estudar outras ferramentas.

 ---

 3º teste: Instalação padrão com um tablespace temporário.

 Matei a instalação anterior. sudo umount /home/tarcisio/tmpfs
 Montei de novo com tudo limpo e criei o tablespace:
 =# CREATE TABLESPACE tmpfs OWNER tarcisio LOCATION '/home/tarcisio/tmpfs';

 ALTEREI o código fonte do pgbench para criar as tabelas e indices dentro do
 tablespace
 Disso: create table tabela_aqui
 Fiz isso: create table tabela_aqui TABLESPACE tmpfs
 E disso: alter table pgbench_*** add primary key (bid)
 Fiz isso: alter table pgbench_*** add primary key (bid) USING INDEX
 TABLESPACE tmpfs
 Compilei o pgbench de novo e rodei:

  tps = 453.644599 (including connections establishing)
  tps = 454.687999 (excluding connections establishing)

 Foi pior que a instalação padrão! Ou seja, talvez não seja uma boa opção.
 (ou benchmark mau feito)
 Se já uso o 

Re: [pgbr-geral] backup windows

2009-09-24 Por tôpico Ralf Schlindwein
-U informa username

qual a variavel da senha??

2009/9/24 Ralf Schlindwein ralfoa...@gmail.com

 @Echo Iniciando processo de backup ...

 for /f tokens=1,2,3,4 delims=/  %%a in ('DATE /T') do set
 Date=%%b-%%c-%%d
 pg_dump.exe -i -h localhost -d *banco* -p 5432 -U postgres -f
 C:\%Date%.backup

 @Echo Fim do processo de backup


 Porem meu banco tem senha e quando eu executo a .bat fica pedindo password
 como eu implemento a senha automatica na .bat ?

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


Re: [pgbr-geral] Memory (heap)

2009-09-24 Por tôpico Euler Taveira de Oliveira
Tarcísio Sassara escreveu:
 Se só quero usar o SGBD para armazenar dados temporários com direito a
 acesso muito rápido, talvez seja melhor usar outra abordagem que não
 empregue o postgres.
Isso é mais comum do que você pensa (ambientes web são os principais usuários
dessa abordagem). A principal utilidade é armazenar dados de sessão. Por que
não armazenar em um sistema de cache de objetos (como por exemplo memcached)?
Simplesmente porque algumas propriedades do SGBD são interessantes (tais como
verificação de chave estrangeira e restrição de integridade).

Para concluir, esse assunto já foi discutido na lista -hackers em meados de
Abril e a conclusão é que a funcionalidade (de ter tabelas temporárias
globais) é útil. Vale ressaltar que o padrão SQL tem a sintaxe CREATE GLOBAL
TEMPORARY TABLE que *não* é exatamente essa funcionalidade. Neste caso, o
autor terá que utilizar outro sintaxe.


-- 
  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


[pgbr-geral] Res: Res: Memory (heap)

2009-09-24 Por tôpico MARCIO CASTRO
Ok;

  A questão é que eu não preciso utilizar o C com o Oracle, pois o PL/SQL é bem 
rápido. Mas se eu precisar, eu posso utilizar o Pro*C.
  Mas a pergunta que não quer calar é a seguinte: porquê é que o PL/pgSQL é tão 
mais lento do que o PL/SQL?









De: Tarcísio Sassara sassara.tarci...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 24 de Setembro de 2009 11:00:19
Assunto: Re: [pgbr-geral] Res: Memory (heap)


Ah, então Márcio, eu cheguei a acompanhar o seu problema. E eu ia responder 
como outra pessoa aqui da lista que era possível utilizar outras linguagens 
para resolver seu problema, mas você acabou com qualquer chances de resposta 
dizendo que não queria alterar seu arquivo sql contendo a estrutura e as 
funções do seu banco. ;-)
Porque tenho quase certeza de que se eu criasse uma versão em C do fibonacci, o 
postgres acabaria com o pl do oracle. Yaaah!
 
Brincadeiras de lado... Você está certo.
Ocorre que: Em alguns momentos devemos usar métodos diferentes para resolver 
problemas semelhantes em SGBDs diferentes. E isso é de se esperar. Não é 
verdade?
Vale o mesmo quando comparado o SQL Server e Oracle.
 
 
Valeu!
 


 
2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br

Caro Tarcísio:

  Achei muito interessante o seu teste, porém, você pode ter pecado na frase 
 O que vale para outros SGBDS. O que eu tenho observado é que o Postgres é 
 extremamente lento em DETERMINADAS situações, comparado ao SGBD Oracle, por 
 exemplo.
  Há alguns dias atrás, postei um exemplo de uma função em PL/pgSQL que 
 simplesmente realizava um loop, onde a cada interação, era somado +1 para 
 uma variável. Fiz o mesmo no Oracle (11g), numa instalação de testes em um 
 Celeron, e foi muito mais rápido!
  Na época, cheguei até a pensar que existia um problema no servidor, no 
 Linux ou na instalação do PostgreSQL. Também não sei se este problema é 
 específico do PL/pgSQL ou do PostgreSQL, mas o fato é que também ainda não 
 achei nenhuma explicação para o ocorrido.


Atenciosamente,

Márcio de Figueiredo Moura e Castro







 De: Tarcísio Sassara sassara.tarci...@gmail.com
Para: fabriziome...@gmail.com; Comunidade PostgreSQL Brasileira 
pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 24 de Setembro de 2009 6:28:09
Assunto: Re: [pgbr-geral] Memory (heap)
 

Bom dia pra todos.

Acompanhando as mensagens de perto, achei o assunto interessante e resolvi 
brincar um pouco.
Mas antes, minha opinião:

Se só quero usar o SGBD para armazenar dados temporários com direito a acesso 
muito rápido, talvez seja melhor usar outra abordagem que não empregue o 
postgres.
Mas e se for o caso da aplicação a ser desenvolvida já faz uso do postgres?
Se já tenho o banco rodando, mas tenho uma tabelinha sem vergonha que uso 
para armazenar algo descartável e que é mais importante um acesso rápido, eu, 
de primeira,
pensaria em criar o tablespace temporário e engoliria o WAL, ou seja, vai ir 
para o WAL mas tudo bem. OK? Bom fiz alguns testes e não foi muito legal o 
resultado para esta abordagem.

Fui para a maquina virtual fazer alguns benchmarks bem por cima.

1º teste: instalação padrão.
2º teste: instalação com todo o cluster e binários em um fs temporário.
3º teste: instalação padrão com um tablespace temporário.

Comandos do pgbench utilizados

# inicializa as tabelas usadas pelo pgbench com um scale factor igual a 10 
no banco de dados postgres
pgbench -i -s 10 postgres

# roda o proprio benchmark com 10 conexões simultaneas 1000 vezes para cada 
uma destas.
pgbench -c 10 -t 1000 postgres


1º teste: Instalação padrão. Resultado:

 tps = 477.656061 (including connections establishing)
 tps = 478.578011 (excluding connections establishing)
---

2º teste: Instalação com todo o cluster e binarios em um fs temporario:

montei um tmpfs seguindo o comando de um dos links fornecidos pelo Fabrízio.
Aumentei o tamanho do fs para conseguir rodar o pgbench:

$ sudo mount -t tmpfs -o size=500M,uid=tarcisio,gid=tarcisio,mode=0700 tmpfs 
/home/tarcisio/tmpfs
configurei e instalei o postgres junto com o contrib tudo ai dentro.
Rodei o pgbench:

 tps = 823.146755 (including connections establishing)
 tps = 825.540711 (excluding connections establishing)

Quase o dobro. Porem, não vejo utilidade/praticidade em colocar o cluster 
inteiro junto com os binários do postgres dentro de um fs temporário.
Se o que quero é algo bem simples e minha aplicação não utilizará o postgres 
pra nada alem disso, prefiro estudar outras ferramentas.

---

3º teste: Instalação padrão com um tablespace temporário.

Matei a instalação anterior. sudo umount /home/tarcisio/tmpfs
Montei de novo com tudo limpo e criei o tablespace:
=# CREATE TABLESPACE tmpfs OWNER tarcisio LOCATION '/home/tarcisio/tmpfs';

ALTEREI o código fonte do pgbench para criar as tabelas e indices dentro do 
tablespace

Re: [pgbr-geral] backup windows

2009-09-24 Por tôpico osvaldo.kussama
2009/9/24 Ralf Schlindwein ralfoa...@gmail.com:
 @Echo Iniciando processo de backup ...

 for /f tokens=1,2,3,4 delims=/  %%a in ('DATE /T') do set Date=%%b-%%c-%%d
 pg_dump.exe -i -h localhost -d banco -p 5432 -U postgres -f
 C:\%Date%.backup

 @Echo Fim do processo de backup


 Porem meu banco tem senha e quando eu executo a .bat fica pedindo password
 como eu implemento a senha automatica na .bat ?



Dê uma olhada nesta thread:
http://www.nabble.com/d%C3%BAvidas-com-o-pg_dump-to11217531.html#a11219247

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


[pgbr-geral] Agora sim, pra quem entende de C

2009-09-24 Por tôpico Jean Domingues

Pessoal, 

estive analisando pra decidir sobre a melhor abordagem para fazer log. O
TableLog é uma otima solução, mas é de difícil manutenção, principalmente
para sistema que está em constante alteração. O função abaixo, em plTcl, faz
o log em uma so tabela, e nao precisa de manutenção em caso de alteração da
tabela. Porem, gera um volume muito grande de dados, pois replica todos os
campos da tabela na tabela de log, quando, a meu ver, deveria guardar so
alteração, por campo (old e new). Alem disso, se estivesse em C seria mais
rapido, eu acredito. Gostaria de saber se alguem tem facilidade para portar
essa função. Porem, pra funcionar, é preciso saber tambem se em C tem como
percorrer o array de campos dos objetos new e old, como em pgTcl; senao, a
função fica inviável.

Jean Domingues - Refrigerantes Garoto.


CREATE OR REPLACE FUNCTION public.log_to_audit_table () RETURNS trigger
AS
$body$
spi_exec SELECT CURRENT_USER AS tguser
spi_exec SELECT relname AS tgname FROM pg_class WHERE relfilenode =
$TG_relid
 
#skip changes on audit_table
if {[string equal -nocase $tgname audit_table]} { return OK }
 
#get PK name
set pk_name 
spi_exec SELECT a.attname AS pk_name FROM pg_class c, pg_attribute a,
pg_index i
 WHERE c.relname = '$tgname'
 AND c.oid=i.indrelid
 AND a.attnum  0
 AND a.attrelid = i.indexrelid
 AND i.indisprimary='t'
 
switch $TG_op {
INSERT {
  set pk_value 
 
  #get PK value
  foreach field $TG_relatts {
if {[string equal -nocase [lindex [array get NEW $field] 0] $pk_name]} {
  set pk_value [lindex [array get NEW $field] 1]
  break;
}
  }
  #log inserted row values
  foreach field $TG_relatts {
if {! [string equal -nocase [lindex [array get NEW $field] 0] $pk_name]}
{
  set modified_field [lindex [array get NEW $field] 0]
  set current_value [lindex [array get NEW $field] 1]
  spi_exec -array C INSERT INTO audit_table(ts, usr, tbl, fld, pk_name,
pk_value, mod_type, old_val, new_val)
VALUES (CURRENT_TIMESTAMP, '$tguser', '$tgname', '$modified_field',
'$pk_name', '$pk_value', '$TG_op', NULL, '$current_value')
}
  }
}
UPDATE {
  set pk_value 
 
  #get PK value
  foreach field $TG_relatts {
if {[string equal -nocase [lindex [array get NEW $field] 0] $pk_name]} {
  set pk_value [lindex [array get NEW $field] 1]
  break;
}
  }
  #log inserted row values
  foreach field $TG_relatts {
#check changed fields
if {[string equal -nocase [array get NEW $field] [array get OLD $field]]
== 0} {
  set modified_field [lindex [array get OLD $field] 0]
  if {[string compare $modified_field ] == 0} {
set modified_field [lindex  [array get NEW $field] 0]
  }
  set previous_value [lindex [array get OLD $field] 1]
  set current_value  [lindex [array get NEW $field] 1]
  spi_exec -array C INSERT INTO audit_table(ts, usr, tbl, fld, pk_name,
pk_value, mod_type, old_val, new_val)
VALUES (CURRENT_TIMESTAMP, '$tguser', '$tgname', '$modified_field',
'$pk_name', '$pk_value', '$TG_op', '$previous_value', '$current_value')
}
  }
}
DELETE {
  set pk_value 
 
  #get PK value
  foreach field $TG_relatts {
if {[string equal -nocase [lindex [array get OLD $field] 0] $pk_name]} {
  set pk_value [lindex [array get OLD $field] 1]
  break;
}
  }
  #log inserted row values
  foreach field $TG_relatts {
if {! [string equal -nocase [lindex [array get OLD $field] 0] $pk_name]}
{
  set modified_field [lindex [array get OLD $field] 0]
  set previous_value [lindex [array get OLD $field] 1]
  spi_exec -array C INSERT INTO audit_table(ts, usr, tbl, fld, pk_name,
pk_value, mod_type, old_val, new_val)
VALUES (CURRENT_TIMESTAMP, '$tguser', '$tgname', '$modified_field',
'$pk_name', '$pk_value', '$TG_op', '$previous_value', NULL)
}
  }
}
}
return OK
$body$
LANGUAGE 'pltcl' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
-- 
View this message in context: 
http://www.nabble.com/Agora-sim%2C-pra-quem-entende-de-C-tp25578019p25578019.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.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] Agora sim, pra quem entende de C

2009-09-24 Por tôpico Roberto Mello
2009/9/24 Jean Domingues ejdom...@yahoo.com.br:

 Pessoal,

 estive analisando pra decidir sobre a melhor abordagem para fazer log. O
 TableLog é uma otima solução, mas é de difícil manutenção, principalmente
 para sistema que está em constante alteração. O função abaixo, em plTcl, faz

Se a estrutura das tabelas está mudando constantemente, então por que
guardar os logs de dados agora? Parece que o sistema ainda está em
desenvolvimento, então os dados não devem ser de produção.

Na última empresa que trabalhei usávamos o tablelog e estabeleci um
sistema de releases que levava em conta modificações no banco de
dados, que tinham que incluir obrigatoriamente, modificações para as
tabelas de log se as tabelas principais fossem alteradas.

Não é de difícil manutenção, mas precisa de manutenção se manutenção
vai ser feita no sistema. Disciplina e consistência são importantes,
mas com documentação e prática tudo fica fácil.

 o log em uma so tabela, e nao precisa de manutenção em caso de alteração da
 tabela. Porem, gera um volume muito grande de dados, pois replica todos os

Já fui por essa estrada, e não me dei bem. Tens que definir POR QUE
estás guardando esses dados e como vais utilizá-los. Guardando TUDO
numa tabela só vais ter muita dificuldade de consultar esses dados,
fazer consultas históricas, trends, etc.

Na experiência que tenho, acaba sendo um falso senso de segurança, por
que se tem os dados, mas eles são de difícil utilização e portanto de
baixo valor.

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


[pgbr-geral] RES: RES: ER

2009-09-24 Por tôpico Kauí Aires Oliveira
Bom dia Aldemir,

 

Você falou algo que não sabia, pois ainda utilizo o Case Studio antes da
compra da Toad. Então quer dizer que retiraram a função de verificação do
MER?

Quanto as formas normais, eu usei uma vez uma ferramenta de um cliente que
informava a ela a FN e ela dava SUGESTÕES, pois verificar é um tanto
relativo. Mas aproveitando o gancho falando de FN, alguém já desenvolveu
algum MER na FN5? Teve ou perdeu performance?

 

Valeu people!

 

Cordialmente,



Kauí Aires Oliveira

Arquiteto de Banco de Dados, Analista de Segurança e DBA

 



 

Esta mensagem eletrônica pode conter informações privilegiadas e/ou
confidenciais, portanto fica o seu receptor notificado de que qualquer
disseminação, distribuição ou cópia não autorizada é estritamente proibida.
Se você recebeu esta mensagem indevidamente ou por engano, por favor,
informe este fato ao remetente e a apague de seu computador imediatamente.

This e-mail message may contain legally privileged and/or confidential
information, therefore, the recipient is hereby notified that any
unauthorized dissemination, distribution or copying is strictly prohibited.
If you have received this e-mail message inappropriately or accidentally,
please notify the sender and delete it from your computer immediately.

 

De: pgbr-geral-boun...@listas.postgresql.org.br
[mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Aldemir
Vieira
Enviada em: quarta-feira, 23 de setembro de 2009 21:09
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] RES: ER

 

Verdade,

Pena que ele não incorporou a funcionalidade de verificação do modelo que o
case studio possuia, uma excelente forma de verificar possíveis falhas na
modelagem.

Falando nisso, alguma outra ferramenta avalia o modelo/base quanto às formas
normais? O System Architect (hoje da IBM) faz muito bem isso, mas ná dá
suporte a Postgres :(.

2009/9/23 Andre Fernandes fernandes.an...@gmail.com

Realmente o Toad data modeler é excelente! 
Faz algum tempo que não uso porque é bem caro, infelizmente. Mas é uma
excelente ferramenta!

2009/9/23 Kauí Aires Oliveira kauiai...@gmail.com

 

Boa Tarde,

Olha gosto muito, do CASE-Studio Uso para modelar já tem uns 6 anos...
Embora agora a quest comprou e se chama Toad data modeler... Recomendo,
muito prático, ótimas ferramentas de reversas... E muito bom os
relatórios...

Abraços,

Kaui Aires


-Mensagem original-
De: pgbr-geral-boun...@listas.postgresql.org.br
[mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Benedito A.
Cruz
Enviada em: quarta-feira, 23 de setembro de 2009 14:50
Para: Comunidade PostgreSQL Brasileira
Assunto: [pgbr-geral] ER




Pegando o gancho da discussão anterior, surgiu uma dúvida: qual o
software que vocês costumam usar para mapear o projeto lógico (Diagrama
ER) para um esquema do BD em SQL?
Já usei Mogwai e dia + er2sql mas queria saber quais as outras opções,
inclusive as mais didáticas (para exemplificar em sala de aula).

Bene


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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






-- 
André de Camargo Fernandes



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




-- 
Forte abraço,
Aldemir Vieira

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


Re: [pgbr-geral] RES: RES: ER

2009-09-24 Por tôpico Aldemir Vieira
Boa tarde Kaui e demais,

Quanto a ter a função, até tem, mas não critica da mesma forma, acho que
eles não usaram a mesma engine.

2009/9/24 Kauí Aires Oliveira kauiai...@gmail.com

  Bom dia Aldemir,



 Você falou algo que não sabia, pois ainda utilizo o Case Studio antes da
 compra da Toad. Então quer dizer que retiraram a função de verificação do
 MER?

 Quanto as formas normais, eu usei uma vez uma ferramenta de um cliente que
 informava a ela a FN e ela dava SUGESTÕES, pois verificar é um tanto
 relativo. Mas aproveitando o gancho falando de FN, alguém já desenvolveu
 algum MER na FN5? Teve ou perdeu performance?



 Valeu people!



 Cordialmente,

 **

 *Kauí** Aires Oliveira*

 Arquiteto de Banco de Dados, Analista de Segurança e DBA



 **



 *Esta mensagem eletrônica pode conter informações privilegiadas e/ou
 confidenciais, portanto fica o seu receptor notificado de que qualquer
 disseminação, distribuição ou cópia não autorizada é estritamente proibida.
 Se você recebeu esta mensagem indevidamente ou por engano, por favor,
 informe este fato ao remetente e a apague de seu computador imediatamente.
 ***

 *This e-mail message may contain legally privileged and/or confidential
 information, therefore, the recipient is hereby notified that any
 unauthorized dissemination, distribution or copying is strictly prohibited.
 If you have received this e-mail message inappropriately or accidentally,
 please notify the sender and delete it from your computer immediately.*



 *De:* pgbr-geral-boun...@listas.postgresql.org.br [mailto:
 pgbr-geral-boun...@listas.postgresql.org.br] *Em nome de *Aldemir Vieira
 *Enviada em:* quarta-feira, 23 de setembro de 2009 21:09
 *Para:* Comunidade PostgreSQL Brasileira
 *Assunto:* Re: [pgbr-geral] RES: ER



 Verdade,

 Pena que ele não incorporou a funcionalidade de verificação do modelo que o
 case studio possuia, uma excelente forma de verificar possíveis falhas na
 modelagem.

 Falando nisso, alguma outra ferramenta avalia o modelo/base quanto às
 formas normais? O System Architect (hoje da IBM) faz muito bem isso, mas ná
 dá suporte a Postgres :(.

 2009/9/23 Andre Fernandes fernandes.an...@gmail.com

 Realmente o Toad data modeler é excelente!
 Faz algum tempo que não uso porque é bem caro, infelizmente. Mas é uma
 excelente ferramenta!

 2009/9/23 Kauí Aires Oliveira kauiai...@gmail.com



 Boa Tarde,

 Olha gosto muito, do CASE-Studio Uso para modelar já tem uns 6 anos...
 Embora agora a quest comprou e se chama Toad data modeler... Recomendo,
 muito prático, ótimas ferramentas de reversas... E muito bom os
 relatórios...

 Abraços,

 Kaui Aires


 -Mensagem original-
 De: pgbr-geral-boun...@listas.postgresql.org.br
 [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Benedito
 A.
 Cruz
 Enviada em: quarta-feira, 23 de setembro de 2009 14:50
 Para: Comunidade PostgreSQL Brasileira
 Assunto: [pgbr-geral] ER




 Pegando o gancho da discussão anterior, surgiu uma dúvida: qual o
 software que vocês costumam usar para mapear o projeto lógico (Diagrama
 ER) para um esquema do BD em SQL?
 Já usei Mogwai e dia + er2sql mas queria saber quais as outras opções,
 inclusive as mais didáticas (para exemplificar em sala de aula).

 Bene


 --
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.

 ___
 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




 --
 André de Camargo Fernandes



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




 --
 Forte abraço,
 Aldemir Vieira

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




-- 
Forte abraço,
Aldemir Vieira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] problemas autovacuum lentidão

2009-09-24 Por tôpico Leandro Müller
Ola turma reparei que meu servidor postgresql esta ficando lento durante o
dia.

Checando o pg_stat_activity reparei que esta executando autovacuum durante o
dia.

 

Examplo
autovacuum: VACUUM public. movimento

 

Será que isso esta deixando mais lento as consultas?

Gostaria de programar fazer o autovacuum durante a madrugada, seria o
correto?

 

At.

 

Leandro Müller

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


Re: [pgbr-geral] problemas autovacuum lentidão

2009-09-24 Por tôpico Osvaldo Kussama
2009/9/24 Leandro Müller leandroli...@muriki.com.br:
 Ola turma reparei que meu servidor postgresql esta ficando lento durante o
 dia.

 Checando o pg_stat_activity reparei que esta executando autovacuum durante o
 dia.



 Examplo
 autovacuum: VACUUM public. movimento



 Será que isso esta deixando mais lento as consultas?

 Gostaria de programar fazer o autovacuum durante a madrugada, seria o
 correto?



Creio que você está confundindo autovacumm [1] com vacuum [2].

Você pode desabilitar o autovacuum (não sei se é uma boa idéia) e
agendar o processamento do vacuumdb [3], mas talvez o mais
interessante seja ajustar os parâmetros do autovacuum.

Osvaldo

[1] 
http://www.postgresql.org/docs/current/interactive/routine-vacuuming.html#AUTOVACUUM
[2] http://www.postgresql.org/docs/current/interactive/sql-vacuum.html
[3] http://www.postgresql.org/docs/current/interactive/app-vacuumdb.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Res: Res: Memory (heap)

2009-09-24 Por tôpico Euler Taveira de Oliveira
MARCIO CASTRO escreveu:
   Mas a pergunta que não quer calar é a seguinte: porquê é que o
 PL/pgSQL é tão mais lento do que o PL/SQL?
 
Não dá para comparar laranja com maça. Fiquei curioso em testar a sua função
mas no momento não tenho um servidor Oracle para testá-la.

O Oracle com certeza deve ter um otimização para tal laço trivial; o
PostgreSQL talvez esteja pecando nisso.

[Fazendo alguns teste de performance...]

A função function1() (versão em PL/PgSQL) e a function2() (versão em C) estão
em anexo.

Pelo que pude notar no oprofile, o problema está relacionado a alocação
excessiva de contexto quando talvez não seja necessário. Estou sem tempo para
investigar o problema agora mas eu reportei o que testei para -hackers [1].

euler=# select function1();
 function1
---
 1
(1 row)

Time: 62107,607 ms
euler=# select function2();
 function2
---
 1
(1 row)

Time: 419,673 ms

[1] http://archives.postgresql.org/pgsql-hackers/2009-09/msg01585.php


PS não responda em outros assuntos. Isso bagunça o histórico da lista e
dificulta que estiver buscando no histórico posteriormente.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/



a.tgz
Description: application/compressed-tar
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Res: Res: Res: Memory (heap)

2009-09-24 Por tôpico MARCIO CASTRO
Caro Euler:

  Muito obrigado pelo seu esforço em me ajudar, mas entenda que me foi vendida 
a idéia de que eu poderia portar todos os programas em PL/SQL para PL/pgSQL, e, 
além disto não ser verdade, a performance mostrou-se muito ruim - para os 
testes que eu realizei.
  Ok; compilando em C fica mais rápido, mas você testou em qual máquina? Ví que 
o primeiro resultado retornou em 65s, tempo semelhante ao servidor da empresa 
que, se não me engano, possui 1 xeon com 4 núcleos com o Post 8.2.7, SUSE 10.3 
64.
  A função, no Oracle, rodou no 11g 11.1.6, também no SUSE 10.3 64, mas em um 
mísero Celeron dual, e foi compilada de duas formas, obtendo o seguinte:

a - INTERPRETED: 9s
b - NATIVE : 3.5s

  Diante de tamanha discrepância, concluí que estava com algum problema no 
servidor do banco, 

mas um colega realizou o mesmo teste no Post, obtendo tempos semelhantes.

  Tentei depois com uma outra função, desta vez para calcular o fibonacci, mas 
o resultado também foi bem mais favorável ao Oracle.
  Esta situação quebrou as minhas pernas - adeus projeto integrado 
Postgres/Oracle. Ou, pelo menos, por enquanto.
  Mas novamente, muito obrigado.


Márcio de Figueiredo Moura e Castro





De: Euler Taveira de Oliveira eu...@timbira.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 24 de Setembro de 2009 18:12:41
Assunto: Re: [pgbr-geral] Res:  Res: Memory (heap)

MARCIO CASTRO escreveu:
   Mas a pergunta que não quer calar é a seguinte: porquê é que o
 PL/pgSQL é tão mais lento do que o PL/SQL?
 
Não dá para comparar laranja com maça. Fiquei curioso em testar a sua função
mas no momento não tenho um servidor Oracle para testá-la.

O Oracle com certeza deve ter um otimização para tal laço trivial; o
PostgreSQL talvez esteja pecando nisso.

[Fazendo alguns teste de performance...]

A função function1() (versão em PL/PgSQL) e a function2() (versão em C) estão
em anexo.

Pelo que pude notar no oprofile, o problema está relacionado a alocação
excessiva de contexto quando talvez não seja necessário. Estou sem tempo para
investigar o problema agora mas eu reportei o que testei para -hackers [1].

euler=# select function1();
function1
---
1
(1 row)

Time: 62107,607 ms
euler=# select function2();
function2
---
1
(1 row)

Time: 419,673 ms

[1] http://archives.postgresql.org/pgsql-hackers/2009-09/msg01585.php


PS não responda em outros assuntos. Isso bagunça o histórico da lista e
dificulta que estiver buscando no histórico posteriormente.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/


  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.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] Res: Res: Memory (heap)

2009-09-24 Por tôpico Marcelo Costa
Olá

2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br

 Ok;

   A questão é que eu não preciso utilizar o C com o Oracle, pois o PL/SQL é
 bem rápido. Mas se eu precisar, eu posso utilizar o Pro*C.
   Mas a pergunta que não quer calar é a seguinte: porquê é que o PL/pgSQL é
 tão mais lento do que o PL/SQL?


Também estou sem tempo para fazer testes mais profundos nesse problema e o
último Oracle 10g que tinha eu detonei já há algum tempo migrando tudo para
PostgreSQL.

Vi que o Euler reportou o problema na hackers e ninguém menos que o Tom Lane
respondeu dando uma explicação o qual eu já imaginava. A PL/pgSQL talvez não
seja a melhor PL que deva-se se usar para esse problema.

Nada que uns bons testes possam te ajudar a tirar as dúvidas que você tem.

O fato de sua função fibonaci não se portar bem com PL/pgSQL não significa
que o PostgreSQL tem baixa performance. Onde trabalho temos tabelas com
milhões de registros e que soframe muitos inserts/updates e nosso SGDB
funciona muito bem e sequer alguém cogita de substitui-lo ou mesmo fala em
baixa performance. Temos softwares qyue funcionam no modelo cloud e nossos
clientes não reclamam de nenhuma lentidão de serviços.

Atte,

-- 
Marcelo Costa
www.marcelocosta.net
-
“You can't always get what want”,

Doctor House in apology to Mike Jagger
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] enterprisedb

2009-09-24 Por tôpico MARCIO CASTRO
Caro colegas:

  Lí alguma coisa sobre o enterprisedb e o Postgre
Plus Standard Server, que promete no site
(http://www.enterprisedb.com/products/postgres_plus/overview.do#ui-tabs-70)
o seguinte: It contains additional powerful features for database
application development that also enable applications written for
Oracle databases to run on top of Postgres database engines.

  Alguém da lista já usou esta ferramenta? O que é que vem de diferente do 
pacote do Post?


Atenciosamente,

Márcio de Figueiredo Moura e Castro


  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.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] enterprisedb

2009-09-24 Por tôpico Marcelo Costa
Boa noite

On Thu, Sep 24, 2009 at 9:45 PM, MARCIO CASTRO 
marciomouracas...@yahoo.com.br wrote:

 Caro colegas:

   Lí alguma coisa sobre o enterprisedb e o Postgre Plus Standard
 Server, que promete no site (
 http://www.enterprisedb.com/products/postgres_plus/overview.do#ui-tabs-70)
 o seguinte: It contains additional powerful features for database
 application development that also enable applications written for Oracle
 databases to run on top of Postgres database engines.

   Alguém da lista já usou esta ferramenta? O que é que vem de diferente do
 pacote do Post?


Nunca utilizei, mas o que tem de diferente e ponto principal na minha opnião
é o expertise de alguns colaboradores do core do PostgreSQL como o Bruce
Momjian.

Que mais detalhes in loco ? Vai lá em
http://pgcon.postgresql.org.br/2009/inscricoes.php te inscreve e conversa ao
vivo e em cores com o Bruce. Ele será um dos palestrantes do PGCon Brasil
2009.

Atte,

-- 
Marcelo Costa
www.marcelocosta.net
-
“You can't always get what want”,

Doctor House in apology to Mike Jagger
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Res: Res: Memory (heap)

2009-09-24 Por tôpico JotaComm
Olá,

Assim como o Marcelo minha empresa tem um case que roda PostgreSQL 8.3 e
também não temos nenhum problema relacionado a performance. O sistema se
comporta muito bem com o elefantinho e não existe a mínima, mínima chance
mesmo de pensar em migração para Oracle.

Apenas a nível de informação o banco hoje tem um tamanho superior a 640GB.

2009/9/24 Marcelo Costa marcelojsco...@gmail.com

 Olá

 2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br

 Ok;

   A questão é que eu não preciso utilizar o C com o Oracle, pois o PL/SQL
 é bem rápido. Mas se eu precisar, eu posso utilizar o Pro*C.
   Mas a pergunta que não quer calar é a seguinte: porquê é que o PL/pgSQL
 é tão mais lento do que o PL/SQL?


 Também estou sem tempo para fazer testes mais profundos nesse problema e o
 último Oracle 10g que tinha eu detonei já há algum tempo migrando tudo para
 PostgreSQL.

 Vi que o Euler reportou o problema na hackers e ninguém menos que o Tom
 Lane respondeu dando uma explicação o qual eu já imaginava. A PL/pgSQL
 talvez não seja a melhor PL que deva-se se usar para esse problema.

 Nada que uns bons testes possam te ajudar a tirar as dúvidas que você tem.

 O fato de sua função fibonaci não se portar bem com PL/pgSQL não significa
 que o PostgreSQL tem baixa performance. Onde trabalho temos tabelas com
 milhões de registros e que soframe muitos inserts/updates e nosso SGDB
 funciona muito bem e sequer alguém cogita de substitui-lo ou mesmo fala em
 baixa performance. Temos softwares qyue funcionam no modelo cloud e nossos
 clientes não reclamam de nenhuma lentidão de serviços.

 Atte,

 --
 Marcelo Costa
 www.marcelocosta.net
 -
 “You can't always get what want”,

 Doctor House in apology to Mike Jagger

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



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


Re: [pgbr-geral] enterprisedb

2009-09-24 Por tôpico JotaComm
Completando. Aproveite esta oportunidade, pois talvez demore um bocado de
tempo para ver o Bruce novamente no Brasil.

2009/9/24 Marcelo Costa marcelojsco...@gmail.com

 Boa noite

 On Thu, Sep 24, 2009 at 9:45 PM, MARCIO CASTRO 
 marciomouracas...@yahoo.com.br wrote:

 Caro colegas:

   Lí alguma coisa sobre o enterprisedb e o Postgre Plus Standard
 Server, que promete no site (
 http://www.enterprisedb.com/products/postgres_plus/overview.do#ui-tabs-70)
 o seguinte: It contains additional powerful features for database
 application development that also enable applications written for Oracle
 databases to run on top of Postgres database engines.

   Alguém da lista já usou esta ferramenta? O que é que vem de diferente do
 pacote do Post?


 Nunca utilizei, mas o que tem de diferente e ponto principal na minha
 opnião é o expertise de alguns colaboradores do core do PostgreSQL como o
 Bruce Momjian.

 Que mais detalhes in loco ? Vai lá em
 http://pgcon.postgresql.org.br/2009/inscricoes.php te inscreve e conversa
 ao vivo e em cores com o Bruce. Ele será um dos palestrantes do PGCon Brasil
 2009.

 Atte,

 --
 Marcelo Costa
 www.marcelocosta.net
 -
 “You can't always get what want”,

 Doctor House in apology to Mike Jagger

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



[]s
-- 
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] Res: Res: Res: Memory (heap)

2009-09-24 Por tôpico MARCIO CASTRO
Caro Jota:

  Obrigado por responder, mas a comparação foi com o PL/pgSQL versus PL/SQL, e 
não com os bancos.


Atenciosamente,

Márcio de Figueiredo Moura e Castro






De: JotaComm jota.c...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 24 de Setembro de 2009 22:53:35
Assunto: Re: [pgbr-geral] Res: Res: Memory (heap)

Olá,

Assim como o Marcelo minha empresa tem um case que roda PostgreSQL 8.3 e também 
não temos nenhum problema relacionado a performance. O sistema se comporta 
muito bem com o elefantinho e não existe a mínima, mínima chance mesmo de 
pensar em migração para Oracle. 

Apenas a nível de informação o banco hoje tem um tamanho superior a 640GB.


2009/9/24 Marcelo Costa marcelojsco...@gmail.com

Olá


2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br

Ok;


  A questão é que eu não preciso utilizar o C com o Oracle, pois o PL/SQL é 
 bem rápido. Mas se eu precisar, eu posso utilizar o Pro*C.

  Mas a pergunta que não quer calar é a seguinte: porquê é que o PL/pgSQL é 
 tão mais lento do que o PL/SQL?


Também estou sem tempo para fazer testes mais profundos nesse problema e o 
último Oracle 10g que tinha eu detonei já há algum tempo migrando tudo para 
PostgreSQL. 

Vi que o Euler reportou o problema na hackers e ninguém menos que o Tom Lane 
respondeu dando uma explicação o qual eu já imaginava. A PL/pgSQL talvez não 
seja a melhor PL que deva-se se usar para esse problema.


Nada que uns bons testes possam te ajudar a tirar as dúvidas que você tem.

O fato de sua função fibonaci não se portar bem com PL/pgSQL não significa que 
o PostgreSQL tem baixa performance. Onde trabalho temos tabelas com milhões de 
registros e que soframe muitos inserts/updates e nosso SGDB funciona muito bem 
e sequer alguém cogita de substitui-lo ou mesmo fala em baixa performance. 
Temos softwares qyue funcionam no modelo cloud e nossos clientes não reclamam 
de nenhuma lentidão de serviços.

Atte,

-- 
Marcelo Costa
www.marcelocosta.net
-
“You can't always get what want”, 

Doctor House in apology to Mike Jagger

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



[]s
-- 
JotaComm
http://jotacomm.wordpress.com



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Res: enterprisedb

2009-09-24 Por tôpico MARCIO CASTRO
Valeu, colega; vou tentar ir.







De: JotaComm jota.c...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 24 de Setembro de 2009 22:55:30
Assunto: Re: [pgbr-geral] enterprisedb

Completando. Aproveite esta oportunidade, pois talvez demore um bocado de tempo 
para ver o Bruce novamente no Brasil.


2009/9/24 Marcelo Costa marcelojsco...@gmail.com

Boa noite


On Thu, Sep 24, 2009 at 9:45 PM, MARCIO CASTRO 
marciomouracas...@yahoo.com.br wrote:

Caro colegas:

  Lí alguma coisa sobre o enterprisedb e o Postgre
Plus Standard Server, que promete no site
(http://www.enterprisedb.com/products/postgres_plus/overview.do#ui-tabs-70)
o seguinte: It contains additional powerful features for database
application development that also enable applications written for
Oracle databases to run on top of Postgres database engines.

  Alguém da lista já usou esta ferramenta? O que é que vem de diferente do 
 pacote do Post?


Nunca utilizei, mas o que tem de diferente e ponto principal na minha opnião 
é o expertise de alguns colaboradores do core do PostgreSQL como o Bruce 
Momjian.

Que mais detalhes in loco ? Vai lá em 
http://pgcon.postgresql.org.br/2009/inscricoes.php te inscreve e conversa ao 
vivo e em cores com o Bruce. Ele será um dos palestrantes do PGCon Brasil 2009.

Atte,

-- 
Marcelo Costa
www.marcelocosta.net
-
“You can't always get what want”, 

Doctor House in apology to Mike Jagger

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



[]s
-- 
JotaComm
http://jotacomm.wordpress.com



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.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] Res: Res: Res: Memory (heap)

2009-09-24 Por tôpico Tarcísio Sassara
2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br:
 ... entenda que me foi vendida a idéia de que eu poderia portar todos os 
 programas em PL/SQL para
 PL/pgSQL, e, além disto não ser verdade, a performance mostrou-se muito ruim
 - para os testes que eu realizei.

Ouve um equivoco ou dois aqui:
Lhe passaram uma informação incompleta ou você compreendeu mal a propaganda.
As rotinas em pl/sql não irão rodar no Postgres sem algum esforço.
Você precisará portar seus scripts para o pl/pgsql.
Mais informações em:
http://www.postgresql.org/docs/8.4/interactive/plpgsql-porting.html

E quanto a performance:
O pl/pgsql funciona muito bem em cenários reais, como criar uma
function que encapsula o
comando insert para um cadastro qualquer ou agrupar alguns outros
comandos sql em uma procedure.

Coloquei entre aspas cenário reais pois determinados cálculos que
são pesados fazem parte de muitos cenários.
Onde trabalho costumamos deixar na aplicação os cálculos complexos.
Utilizamos o R[1] para isto. Esta linguagem possui uma interface de
comunicação (DBI)
que nos permite conectar no postgres e retornar os dados que serão
utilizados para os cálculos e gerar os gráficos.

[1] O R é uma linguagem para cálculos estatísticos.
http://www.r-project.org/

Abraço!

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


Re: [pgbr-geral] Res: Res: Res: Memory (heap)

2009-09-24 Por tôpico Euler Taveira de Oliveira
MARCIO CASTRO escreveu:
   Muito obrigado pelo seu esforço em me ajudar, mas entenda que me foi
 vendida a idéia de que eu poderia portar todos os programas em PL/SQL
 para PL/pgSQL, e, além disto não ser verdade, a performance mostrou-se
 muito ruim - para os testes que eu realizei.
As linguagens possuem sintaxes bem similares; é claro, que as particularidades
do Oracle embutidas na PL/SQL você terá que reescrever. Não há almoço grátis. ;)

As suas funções em PL/PgSQL serão tão irreais quanto a que você apresentou? É
como o Tom disse na outra lista: plpgsql foi desenhada para cenários onde há
bastante acesso a dados.

Particularmente eu acho muito difícil tu comparares laranja com maça. Até
porque se tu montares um teste querendo comparar puramente a velocidades dos
motores das duas linguagens vais ter que desconsiderar as diferenças de tempo
com relação ao acesso aos dados.

   Ok; compilando em C fica mais rápido, mas você testou em qual máquina?
No meu notebook (Pentium M 1.86 GHz). A execução da função em questão é
puramente CPU-bound, ou seja, quanto mais poderosa a sua CPU mais rápido será
a execução. A mesma função em PL/Perl executou em ~ 25 segundos.

   Tentei depois com uma outra função, desta vez para calcular o
 fibonacci, mas o resultado também foi bem mais favorável ao Oracle.
   Esta situação quebrou as minhas pernas - adeus projeto integrado
 Postgres/Oracle. Ou, pelo menos, por enquanto.
 
Acho que você *não* está fazendo um comparação justa. Digo isso porque a
principal vantagem de ter funções no SGBD é justamente tirar proveito do
acesso aos dados. Sugiro que realize testes mais sérios antes de ficar tirar
conclusões utilizando apenas um caso que está muito longe de fazer parte de
qualquer tipo de aplicação real.


-- 
  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