Em 10 de fevereiro de 2016 07:32, Flavio Henrique Araque Gurgel < [email protected]> escreveu:
> Pessoal >> >> O algoritmo MERGE-JOIN ou HASH-JOIN normalmente é escolhido pelo >> Otimizador ao inves do NESTED-LOOP, devido a ter melhor desempenho. >> > > Não, ele é escolhido quando tem um custo mais baixo. > Ok, isso mesmo que eu queria dizer > > No entanto, se considerarmos a utilização de discos SSDs, que tem >> velocidade de leitura mais de 100 vezes mais rápida que um HDD o >> algoritmo NESTED-LOOP pode ser uma melhor opção, devido a trabalhar >> somente com leituras. Outro fato é que o MERGE-JOIN e HASH-JOIN >> > > Se considerarmos que o custo de leitura aleatória é mais baixo, um nested > loop *pode* ser menos custoso em relação aos outros métodos de acesso. > > Discos SSD não são "100x mais rápidos" que discos rotativos. Isso depende > muito da arquitetura de todo o sistema de armazenamento. > > Aqui eu falei que os SSDs são 100 vezes mais rápidos, mas somente para leitura.... deixo aqui uma referencia, de pesquisadores da HP que fizeram um estudo, já antigo... http://www.cs.cmu.edu/~damon2007/pdf/graefe07fiveminrule.pdf Já vi artigos atuais em que os SSDs atuais chegam a ser 1000 vezes mais rápidos.... Veja na pagina 2 do artigo que o custo de leitura de um SSD é 0,16 ms enquanto que de um HD é 12 ms, ou seja 75 vezes mais rápido. > O que é mais interessante nos SSDs é que o "custo" de leitura aleatória > (randômica) é próximo, às vezes igual, ao "custo" de leitura sequencial. > > necessitam de bastante escrita, quando os dados não cabem na RAM, e se >> > > Não há escrita em SELECT. Você está falando de temporários? Ajustar o > work_mem para a consulta é uma alternativa válida em muitos casos, mesmo > quando se tem SSD, que em alguns casos é péssimo em escrita. > > Estou falando de escrita, que são utilizadas na Junção para armazenar resultados intermediários.. > considerarmos o maior preço por gigabyte de um SSDs, isso também deve >> > > O custo que estou falando não é preço (apenas pra ficar claro). Sim estou falando de dinheiro... > > > ser considerado. Estou considerando ambientes exclusivos com discos SSDs. >> >> Alguém sabe se o PostgreSQL consegue identificar se o armazenamento está >> sendo em um SSD para poder escolher melhor o algoritmo de Junção ? >> > > Você precisa especificar o "custo de fazer leitura em disco". Para isso, > você precisa ajustar os parâmetros random_page_cost e seq_page_cost do seu > servidor de banco de dados. > > Muitos administradores tem colocado 1 como random_page_cost quando > trabalha com SSDs, ou seja, assume-se que a leitura aleatória tem o mesmo > "custo" que a leitura sequencial. > Excelente opção. > > No seu caso, você precisa testar. Abra uma sessão psql, altere os valores > nesta sessão com SET, e teste suas consultas. > > Como os SSD tem performance ruim em escrita, acredito que vou tentar implementar um ambiente hibrido, deixando os HDD para os arquivos write-intensive (temp, logs) assim deixaria SSD somente para tabelas que tenham bastante leitura... vale explicar para quem não tenha experiencia com SSDs que a escrita não tem boa performance, devido a não possibilidade de sobrescrever ou atualizar dados. Ao invés disso, é realizado o processo conhecido como *erase-before-write* onde um bloco inteiro deve ser apagado e depois os novos dados podem ser escritos nas páginas do bloco, isso significa que todas as outras páginas do bloco (que nao precisariam ser alteradas), precisam ser lidas e, em seguida, escritas novamente. Em um SSD um dado só pode ser escrito em um bloco vazio, por isso o processo de erase-before-write. Alguem teria uma sugestão de quais seguimentos de arquivos deixaria no SSDs e quais nos HDs ? qualquer ajuda sera bem vinda. []`s Neto > []s > Flavio Gurgel > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
