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. 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/<http://www.midstorm.org/%7Etelles/2007/07/05/database-overkill/> > > > > -- > 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 > > -- Tarcisio F. Sassara
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
