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.

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.

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.

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).

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.

No seu caso, você precisa testar. Abra uma sessão psql, altere os valores nesta sessão com SET, e teste suas consultas.

[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a