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 <[email protected]> > 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 <[email protected]> > *Para:* [email protected]; Comunidade PostgreSQL Brasileira < > [email protected]> > *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 <[email protected]> > >> >> >> 2009/9/23 Euler Taveira de Oliveira <[email protected]> >> >>> 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. Fábio Telles [1] que >> falava sobre vários SGBDs e creio que seja interessante dar uma olhada >> nessas informações. >> >> [1] http://www.midstorm.org/~telles/2007/07/05/database-overkill/ >> >> >> >> -- >> Fabrízio de Royes Mello >> >> Blog sobre TI: http://fabriziomello.blogspot.com >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > Tarcisio F. Sassara > > ------------------------------ > Veja quais são os assuntos do momento no Yahoo! + Buscados: Top > 10<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/>- > Celebridades<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/>- > Música<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/>- > Esportes<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/> > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Tarcisio F. Sassara
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
