Bom, algumas observações:

> A questão é que tentei valores das estatisticas justamente pro
> PostgreSQL não despender tempo desnecessário com o planejamento
> (verifiquei colunas estimadas e retornadas como recomendastes)... o caso
> é que o valor que melhor se ajustou foi 1000,

Idem, para todos os casos em que algum dia me dei ao trabalho de otimizar
qualquer consulta em Postgres.

>    Tempo de Execução: 84195.499 ms *MENOR TEMPO DE TODOS*

O tempo até que é útil, mas considerando a disparidade de resultados, é bom
mandar logo o EXPLAIN completo da query para ver o que ele fez em cada caso.
Se o plano foi o mesmo (entre as estatísticas é possível), a diferença se
deve ao cache. Agora, a diferença entre os tempos com e sem estatísticas só
pode ser explicada por um plano diferente. Sabendo o plano, dá para imaginar
o que o Postgres usou ou deixou de usar para chegar ao plano "ideal".

> Bom, agora falando sobre o que eu considero mais importante: é muito
> difícil você conseguir obter bons resultados rodando em um notebook, com
> apenas 800Mhz por core.

O problema não é resultado absoluto, e sim diferença entre resultados no
mesmo ambiente.
Se o importante é a comparação entre resultados, qualquer processador serve.
Se acha que esse processador é lento, seria bom mostrar que parâmetro faria
ele usar outro recurso de forma a executar a consulta num tempo decente.


Mozart Hasse


_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a