Caros Colegas, Há algum tempo estava analisando uma base de dados e verifiquei que diversas colunas das tabelas dessa base estavam com a coleta de estatisticas desabilitada. Na saida de um dump da estrutura da base encontrei algo como:
ALTER TABLE tabela ALTER COLUMN coluna SET STATISTICS 0; Essa desativação não estava em TODAS colunas das tabelas da base de dados, verifiquei isso facilmente com alguns SQLs, dentre eles: SELECT * FROM pg_attribute WHERE attstattarget = 0 AND attnum > 0; Fiquei surpreso que essas estatisticas estivessem desabilitadas então resolvi logo habilitadas (colocando o valor -1 pra buscar da configuração do postgresql.conf conforme documentação oficial) mas o que fiquei mais surpreso ainda foi com o resultado... foi desastroso pois degradou a performance das queries... e naquele final de semana, oportunamente, foi executado um REINDEX DATABASE e após um VACUUM ANALYZE, este último é executado diariamente... Verifiquei todas configurações (shared_mem, work_mem, effetive_cache_size, etc...) para ver se conseguiria mudar o resultado pois uma simples consulta que demorava de ~3seg começou a demorar ~907seg... muita diferença não é mesmo... Com isso fui fazer uns EXPLAINs das queries no servidor que habilitei as estatisticas para comparar com outro onde as estatisticas ainda estavam desabilitadas e, É ÓBVIO, deu diferença no resultado dos EXPLAINs... até ai sem problemas, o problema é que com a estatisticas HABILITADAS ficou MUITO PIOR... será que não deveria ficar melhor?? A diferença significativa no resultado dos EXPLAINs é que na base que as estatisticas estavam desabilitadas no resultado tinha um "BITMAP HEAP SCAN" resultando num custo bem menor que o da base que as estatisticas estavam habilitadas o qual não fazia esse bitmap_scan, fazendo um index_scan normal... e não se preocupem que verifiquei e NOS 2 SERVIDORES as configurações dos métodos do planejador estão iguais: enable_bitmapscan = on enable_hashagg = on enable_hashjoin = on enable_indexscan = on enable_mergejoin = on enable_nestloop = on enable_seqscan = off enable_sort = on enable_tidscan = off Com isso tudo, sem entender nada e ter levado uma surra do elefantinho resolvi tomar a seguinte "medida DRÁSTICA": 1) Desabilitei as COLUNAS que assim estavam antes do "meu ato heróico" de habilitalas (deixei a base de dados no estado original) 2) Rodei um DELETE na pg_statistic... isso mesmo... um DELETE nela... 3) Rodei um ANALYZE na base de dados... Meus amigos adivinhem o resultado... as queries voltaram ao normal... exatamente como eram antes... tudo rápido q é uma beleza... a query que demorava ~907seg antes desse procedimento voltou a demorar apenas ~3seg... Agora gostaria de saber se algum dos colegas sabe o porque desse comportamento, no mínimo estranho e/ou duvidoso, do planejador do nosso amigo PostgreSQL. Cordialmente, -- Fabrízio de Royes Mello Coordenador Desenvolvimento de Software [EMAIL PROTECTED] DBSeller Informática Ltda. - http://www.dbseller.com.br (51) 3076-5101 _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
