Re: [pgbr-geral] init.d inicializando o postgres automaticamente
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)
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
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
@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/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)
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)
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
-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)
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)
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/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
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/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
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
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
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/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)
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)
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)
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
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
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)
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
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)
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
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/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)
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
