Olá, Fiz mais um teste, uma copia do banco produção no servidor de produção e rodando o SQL Total runtime: 4674.343 ms Como fazer o banco produção ficar bom sem ter q recriar ele ?
Novo Explain Analyse https://docs.google.com/document/d/1jTJqe8iKot5Gm_5ywddwG19qSzFIau4ygnHf1khut38/edit?usp=sharing Obrigado Fernando Silveira Em 5 de dezembro de 2014 16:12, Fernando Nadir da Silveira < [email protected]> escreveu: > Matheus, > > Separando agora ficou muito melhor para entender, mais ainda não entendo > porque usa planos diferente, estou me afundando mais. > > Analyse separado > > > https://docs.google.com/document/d/1uORyqq1-miicVPsUR9d_dF1iIjOQgqVLmZ5krHaPpH0/edit?usp=sharing > > Abs > Fern > > Em 5 de dezembro de 2014 15:50, Fernando Nadir da Silveira < > [email protected]> escreveu: > > Ola Matheus, Boa Tarde, >> >> É uma coisa maluca. >> >> São vários sub select sim, foi criado pelo pessoal do desenvolvimento, e >> me passaram dizendo que no produção/desenvolvimento o tempo de execução era >> muito diferente, não sou o mais expert no SQL, mais o restante eu já >> analisei tudo, O conjunto de maquina é DELL, são duas laminas M620, da >> Blade M1000E, ligadas num storage Equalogic por fibra através de um force >> 10. >> >> SQL da discordia >> >> https://docs.google.com/document/d/1tPXuFP2jAdH7rkMYX3zkKtsSpXex6p4Uaw3-tspCjYg/edit?usp=sharing >> >> >> * Produção >> effective_cache_size = 64GB >> wal_buffers = 8MB >> >> >> * Desenvolvimento >> effective_cache_size = 4GB >> wal_buffers = 4MB >> >> >> * Igual nos dois >> checkpoint_segments = 16 >> checkpoint_completion_target = 0.9 >> default_statistics_target = 50 >> constraint_exclusion = on >> log_destination = 'stderr' >> >> >> ANALYZE separado não fiz ... vou brincar com isso, e posto os resultados. >> >> Vou conversar com o pessoal aqui sobre id_tipm. Obrigado >> >> Abs >> Fern >> >> >> Em 5 de dezembro de 2014 15:04, Matheus de Oliveira < >> [email protected]> escreveu: >> >>> >>> 2014-12-05 14:44 GMT-02:00 Fernando Nadir da Silveira <[email protected] >>> >: >>> >>>> * Explain Produção >>>> >>>> >>>> https://docs.google.com/document/d/18yz42q4KWB0IBcjKTQ9dVuMlkb9ZLiBrKdsh1UySou4/edit?usp=sharing >>>> >>>> * Explain Desenvolvimento >>>> >>>> >>>> >>>> https://docs.google.com/document/d/10msO31cKa9cX-MH-epAdUgqPtIfrbtf8pwQyCxIe7AE/edit?usp=sharing >>>> >>> >>> A diferença é *bem* maior do que você tinha dito antes. Sendo 168 >>> *segundos* na produção e 5 *segundos* no desenvolvimento, e não *ms* como >>> você tinha comentado antes. >>> >>> Bem, visivelmente os planos estão diferentes, principalmente envolvendo >>> a junção das tabelas itenstabela,tabela e produto. Tenho algumas perguntas: >>> >>> 1) Me parece que tem várias subconsultas nas mesmas tabelas, é possível >>> "juntar" numa só? Poderia compartilhar a consulta também? >>> 2) Você executou o comando ANALYZE nas tabelas envolvidas antes de >>> verificar os planos (em ambos ambientes)? Alguma mudança nos planos se o >>> fizer? >>> 3) Certeza que nenhum parâmetro a mais diferente? Nem mesmo >>> effective_cache_size? >>> 4) Há um índice no campo "id_tipm" da tabela "produto"? Se não, >>> recomendo adicionar (não acho que vai resolver o problema da diferença, mas >>> vai ajudar na performance geral). >>> >>> Atenciosamente, >>> -- >>> Matheus de Oliveira >>> Analista de Banco de Dados >>> Dextra Sistemas - MPS.Br nível F! >>> www.dextra.com.br/postgres >>> >>> >>> _______________________________________________ >>> 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
