Euler Taveira de Oliveira escreveu: > Sergio Santi escreveu: > >> OK, lá vai. >> >> Postgres.conf >> >> Parâmetro Padrão ServLento ServRápido >> max_connections 100 70 100 >> shared_buffers 32MB 1000MB 32MB >> work_mem 1MB 64MB 1MB >> maintenance_work_mem 16MB 256MB 16MB >> max_fsm_pages 204800 1000000 204800 >> max_fsm_relations 1000 2000 2000 >> checkpoint_segments 3 3 10 >> enable_seqscan on off off >> enable_tidscan on off off >> effective_cache_size 128MB 256MB 128MB >> >> Consulta usada tanto no ServLento quanto no ServRapido >> >> > A causa da lentidão é que os planos estão pegando índices diferentes. O índice > NotaFiscal_Impressora_Intervencao_Cupom_I escolhido para consulta lenta está > com uma estimativa totalmente errada. > Os índices NotaFiscal_Impressora_Intervencao_Cupom_I, > NotaFiscal_CodigoOperacaoEstoque_I e NotaFiscal_DataEmissao_I estão com > estimativas fora da realidade. Você fez um REINDEX neles? Você tentou aumentar > o default_statistics_target das colunas que participam do índice para ver se > as estimativas melhoram? > Além disso, eu *não* aconselharia desabilitar _seqscan_ nem _tidscan_. Mas > aconselharia aumentar o effective_cache_size e checkpoint_segments. > > > Isso implica que nem sempre um servidor com hardware melhor e mais rápido e configurações maiores de PostgreSQL vai oferecer uma resposta mais rápida? Isto é, sob condições mais "apertadas" o PostgreSQL faz estimativas melhores e mais eficientes?
-- Benedito A. Cruz Centro de Referência em Informação Ambiental - CRIA email [email protected] fone 55 19 3288 0466 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
