Fabrízio de Royes Mello escreveu: > Euler Taveira de Oliveira escreveu: >> Sim. Sem isso você está encorajando o PostgreSQL a excluir alguns >> possíveis caminhos que o planejador pode percorrer por questões de pouca >> memória. >> > E quais são esses *possíveis caminhos*??? Quais parâmetros interferem??? > Os caminhos são diversos. Os parâmetros que interferem estão nas seções 'Resource Usage' (Memory) e 'Query Tuning'.
> >> Não, estou me referindo a cache do *SO*; a do PostgreSQL se perde em um >> reínicio do serviço. >> > Apesar de eu não acreditar que isso vá fazer diferença vou fazer o que > recomendas e refazer os testes... > Faz sim. > Que escolhas dependem de que parâmetros??? Isso é muito subjetivo... > terias como exemplificar isso? > > Tipo se alterar parametro tal aumenta ou diminui o tempo de > planejamento, ou utiliza uma estratégia diferente de planejamento, etc... > Isso é tema para um livro. ;) Para que você consiga otimizar consultas SQL, você deve conhecer os algoritmos de junção (hash join, merge join, nested loop), algoritmos de agregação, funcionamento de índices (inclusive os funcionais e parciais) e *principalmente* o modelo de custo utilizado pelo PostgreSQL (src/backend/optimizer/path/costsize.c pode ser um bom começo). Se houvesse uma receita de bolo com certeza alguém já tinha escrito. Há livros que tratam desse assunto mas nenhum específico ao PostgreSQL. Tem um livro que trata do assunto de maneira genérica e que eu particularmente recomendo (SQL Tuning, Dan Tow). Ele aborda alguns dos pontos que falei acima. Apesar de já ser tarde, eu vou exemplificar a dinâmica do modelo de custo do PostgreSQL. Ao alterar o parâmetro random_page_cost, o algoritmo de junção interna foi alterado. Por quê? Justamente porque ao favorecer a busca sequencial (diminuindo o random_page_cost) fizemos com o que o custo do 'merge join' fique mais vantajoso do que um 'hash join'. regression=# set random_page_cost to 2.5; SET regression=# explain analyze select count(*) from tenk1 a inner join tenk1 b on (a.unique1=b.thousand) where b.unique2 > 1000 limit 300; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------ Limit (cost=1330.41..1330.42 rows=1 width=0) (actual time=163.743..163.748 rows=1 loops=1) -> Aggregate (cost=1330.41..1330.42 rows=1 width=0) (actual time=163.736..163.737 rows=1 loops=1) -> Hash Join (cost=605.00..1307.78 rows=9052 width=0) (actual time=66.528..148.729 rows=8999 loops=1) Hash Cond: (b.thousand = a.unique1) -> Seq Scan on tenk1 b (cost=0.00..470.00 rows=9052 width=4) (actual time=1.331..21.611 rows=8999 loops=1) Filter: (unique2 > 1000) -> Hash (cost=445.00..445.00 rows=10000 width=4) (actual time=65.043..65.043 rows=10000 loops=1) -> Seq Scan on tenk1 a (cost=0.00..445.00 rows=10000 width=4) (actual time=0.013..35.482 rows=10000 loops=1) Total runtime: 163.979 ms (9 registros) regression=# set random_page_cost to 2.2; SET regression=# explain analyze select count(*) from tenk1 a inner join tenk1 b on (a.unique1=b.thousand) where b.unique2 > 1000 limit 300; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=1234.92..1234.93 rows=1 width=0) (actual time=143.700..143.705 rows=1 loops=1) -> Aggregate (cost=1234.92..1234.93 rows=1 width=0) (actual time=143.692..143.693 rows=1 loops=1) -> Merge Join (cost=1.02..1212.29 rows=9052 width=0) (actual time=0.175..128.241 rows=8999 loops=1) Merge Cond: (a.unique1 = b.thousand) -> Index Scan using tenk1_unique1 on tenk1 a (cost=0.00..961.94 rows=10000 width=4) (actual time=0.091..3.583 rows=1001 loops=1) -> Index Scan using tenk1_thous_tenthous on tenk1 b (cost=0.00..1000.24 rows=9052 width=4) (actual time=0.059..76.166 rows=8999 loops=1) Filter: (b.unique2 > 1000) Total runtime: 143.972 ms (8 registros) -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral