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

Responder a