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 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
>pgbr-geral@listas.postgresql.org.br
>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
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
