Em 1 de março de 2016 14:00, Tiago José Adami <adam...@gmail.com> escreveu:
> Em 29 de fevereiro de 2016 18:01, Neto pr <neto...@gmail.com> escreveu: > > Mas teria como saber um valor (nem que for aproximado) de tamanho de > > tabela, em que seria interessante criar um índice (considerando o > > tamanho da ram como referencia)? > > Não sei se entendi direito todo o seu questionamento, mas, mesmo que > toda a tabela esteja em memória o acesso a índice é muito mais rápido > que um tablescan, uma varredura completa sobre os registros da tabela > - considerando que ambos estão em memória. > > Há alguns casos, claro, conforme o tipo da consulta, que o otimizador > julga um tablescan mais rápido que um indexscan. Isso pode acontecer, > por exemplo, quando você tem uma tabela com dados de produto (de 1 a > 10, digamos) e você pesquisa todos os produtos de 1 a 9, excluindo > apenas o 10. Neste caso um tablescan será menos custoso que ter que > pesquisar o índice e depois buscar os registros na tabela (caso hajam > mais colunas na consulta além das existentes no índice). Essa função é > do otimizador interno, e pode ter certeza que ele é mais inteligente > que qualquer pessoa na hora de decidir isso (desde que as métricas > estejam bem atualizadas, portanto o VACUUM ANALYZE é essencial). > > Um consenso praticamente unânime dentre os mais experientes da lista é > que otimização precoce é um tiro no pé. Você deve planejar índices > conforme o tipo das consultas que são executadas. Não existe uma > fórmula para dizer se você deve ou não criar um índice com base apenas > em informações de hardware do servidor, tamanho e estrutura das > tabelas. > > > TIAGO J. ADAMI > http://www.adamiworks.com > @tiadami > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Concordo com o que o Tiago disse. Costuma ser contra-producente fazer este tipo de análise com antecedência pois dificilmente as estimativas da equipe de negócios ou de desenvolvimento se concretizam quanto à utilização do sistema. A falta de índices só seria benéfica em um ambiente muito pequeno onde, de qualquer forma, a criação de índices não seria um problema na ocupação de espaço em disco sendo que, para performance, o planejador é mais capacitado para escolher o melhor caminho (desde que as estatísticas estejam sendo atualizadas constantemente). De qualquer forma, na nova versão do PostgreSQL temos os índices BRIN, que permitem uma grande economia de espaço em disco com apenas uma pequena queda na performance em relação ao BTREE, desde que os dados sejam ordenados naturalmente (ex.: sequences de pks e fks, datas de inserção que apenas são adicionadas e nunca modificadas, etc). Portanto pode-se fazer testes no sentido de comparar a performance e uso de disco em cada uma das situações de uso do sistema. Por fim, a quantidade de memória RAM disponível no servidor não deveria ser um fator a ser considerado de maneira absoluta, ou seja, você não deveria mudar seu sistema ou seu banco de dados por causa disso. É o hardware que tem que se adequar ao software e não o contrário. Obviamente você deve fazer um bom trabalho de análise e tuning para utilizar de maneira eficaz e eficiente seus recursos, mas dado que você já fez (ou está fazendo isso) o próximo passo é adicionar hardware caso ele esteja faltando. Sei que no mundo real isto nem sempre acontece, mas é sua responsabilidade levantar a questão da necessidade e apontar todo trabalho já feito para otimizar o uso dos recursos existentes. Att., Felipe
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
