A sessão visa demonstrar, partindo do zero, um roteiro para realizar a otimização de consultas em PostgreSQL, com dados de um ambiente real de produção. Este ambiente caracteriza-se por quatrocentas e cinquenta bases, de diferentes tamanhos, em um cluster PostgreSQL replicado em cascata, no qual são emitidos aproximadamente cento e cinquenta mil documentos fiscais por mês. Inicialmente serão abordados parâmetros de configuração que nos auxiliam na geração de um arquivo de log relevante para o tema. De posse deste arquivo, a análise será feita de duas maneiras: utilizando o pgbadger, ou via shell scripts unidos a planilhas de cálculo. Este último método facilita a comparação histórica do comportamento do banco de dados. Em seguida, o comando EXPLAIN será abordado, bem como os comandos de atualização das estatísticas do otimizador de consultas, de garbage collection e sua automatização. No tocante a otimização, será descrito o uso de índices e seu custo em termos de tempo e utilização de espaço. Também serão apresentadas alternativas para reduzir o espaço por eles utilizados. Apesar da excelente performance do otimizador genérico de consultas (Generic Query Optimyzer) a ordenação de JOINs pode, em casos específicos, resultar em ganhos de performance. Ato contínuo, serão demonstradas as formas de utilização de Common Table Expression e Window Functions, recursos que auxiliam na otimização de consultas e que mesmo sendo muito eficientes, tem o uso pouco difundido. Common Table Expressions podem ainda ser aliadas em cenários de bancos de dados replicados em que a réplica é utilizada como uma base somente-leitura.

1. PGDAY Campinas – 2016PGDAY Campinas – 2016
PostgreSQL – OtimizaçãoPostgreSQL – Otimização

2. ContextualizaçãoContextualização
● Utilização de PostgreSQL desde 2001
– 7.2, 7.4, 8.0, 8.2, 9.1, 9.2, 9.4, 9.5 ….
● Cenários distintos
– Servidores com um grande BD, replicados
– Servidores com muitos BDs (~ 400), de tamanhos
distintos (entre 20 MB e 10GB) e muitos usuários
simultâneos, replicados
● ~ 400 tabelas, 180.000 CTRCs emitidos/mês

3. ContextualizaçãoContextualização

4. O sistema está lento!O sistema está lento!
● Mais Frete
– Aproximadamente 3.000 arquivos
● Todos acessam o banco de dados
Quem causa lentidão? ?
– Normalmente consultas
● Exceção: cargas de dados

5. Análise de custo de execuçãoAnálise de custo de execução
● EXPLAIN
– Custo = leitura de páginas de disco
– Analyze: executa efetivamente a consulta
● Atenção: teste efetivamente suas alterações
● CTRC
– Conhecimento de Transporte Rodoviário de Carga
● CT-e

6. ÍndicesÍndices
● Formas de busca
– Sequenciais
– Indexadas
● Diversos tipos de
índice
● Consultas de 01 a 04
● Custo
– Tempo de criação
– Espaço utilizado
● Mulltiplicar por 400
– Nem sempre
utilizados
– Consultas 05 a 08

7. ÍndicesÍndices
● Otimização de performance
– Menor amostra
● Consultas 09 a 12
● Redução de espaço utilizado
– Partial index
● Consultas 13 e 14

8. Ordenação de JOINsOrdenação de JOINs
● A sequencia dos JOINs pode interferir no
plano de execução da consulta
– Priorizar tabelas filtradas e/ou indexadas
– Consultas 15 a 18 (vi / vimdiff)
– join_collapse_limit

9. Uso do WITHUso do WITH
● Similar a uma tabela temporária
– Válido por uma consulta
● Substitui
– SUBSELECTs no WHERE
– JOINs com grande tabelas ou não indexados
– Consultas 19 a 23
● Não altera pg_attribute

10. Performance em Instruções SemelhantesPerformance em Instruções Semelhantes
● Instruções semanticamente idênticas podem
possuir planos de execução distintos
– Consultas 24 e 25

11. Window FunctionsWindow Functions
● Evitam sub-SQLs
● Possibilitam ranqueamento,
– Consultas 26 a 29

12. Outras alternativasOutras alternativas
● Hardware
– Discos
– Memória
– Processador
● Configuração
– work_mem
– statement_timeout

13. EstatísticasEstatísticas
● Tabelas mudam
– Índices antigos não refletem mais realidade atual
– ANALYZE
● Alterações e exclusões
– Não apagam fisicamente
● VACUUM e VACUUM FULL;
● Autovacuum

14. HistóricoHistórico
● Atua Sistemas de Informação
– Fundada em 2001
● Sistemas para Transportadoras (Mais Frete, Mais Frota)
● Desenvolvidos em PHP e PostgreSQL
● Jaguar
– Infraestrutura de Rede
– Outros sistemas (Mais Contratos, Efesus …)
– Equipe: ~ 40 colaboradores (Set/2016)
● Desenvolvimento, Redes, Suporte, Comercial e Adm
● Crescimento

15. A AtuaA Atua

16. Dúvidas?Dúvidas?
Álvaro Nunes Melo
alvaro@atua.com.br
www.atua.com.br/vagas/
facebook.com/AtuaSistemas