> Obrigado Flavio,
>
> [..]
>
>
>
> O que diz
> SHOW random_page_cost;
>
> Em cada servidor, antes de fazer o seu SET e antes do explain analyze?
>
> MASTER e SLAVE:
> random_page_cost
> ------------------
> 2
O default pra essa GUC é 4. Por que está como 2?
> > *Dúvidas*
> > - Por que o planejador parou de utilizar o Index?
>
> Pode ser uma diferença de configuração.
> Pode ser que você esteja usando o Slony mas as tabelas são diferentes em
> cada servidor, o Slony permite esse tipo de coisas, por exemplo, a
> tabela no servidor de destino tem mais linhas que na tabela de origem,
> ou mesmo outras colunas.
>
> A Estrutura é identica, Master e Slave, colunas, tuplas e indexs.
>
> O mais curioso, que criei uma tabela identica no SLAVE como auxiliar
> para ver se utiliza o index, mas também não utilizou.
Você provavelmente tem diferenças estatísticas entre as tabelas, sendo
que no escravo a ordenação das linhas segue algum padrão (como um id ou
data crescente).
O que sai desta consulta, igualmente nos dois servidores:
SELECT attname, inherited, n_distinct,
array_to_string(most_common_vals, E'\n') as most_common_vals
FROM pg_stats
WHERE tablename = 'sua_tabela';
Note que você precisa colocar o nome da tabela em 'sua_tabela'
(desculpe, você cortou nesta resposta e eu já apaguei da minha caixa de
entrada, não posso buscar agora no histórico da lista).
> Isso que é minha preocupação, utilizando este SET, estaria "resolvendo"
> o problema desta query, mas se conseguir identificar a causa deste
> problema, posso evitar futuros erros.
Sim, você está analisando corretamente, o melhor é identificar a causa.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
