Em 7 de junho de 2016 11:22, Flavio Henrique Araque Gurgel <[email protected]
> escreveu:
> > 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).
>
>
*MASTER*:
attname | inherited | n_distinct | most_common_vals
------------------+-----------+-------------+--------------------------------
id | f | -1 |
cpf | f | -1 |
nome | f | 1.17187e+06 | MARIA JOSE DA SILVA
+
| | | MARIA
APARECIDA DOS SANTOS +
| | | ANTONIO DOS
SANTOS +
*(lista mais alguns nomes, cortei pra não ficar muito grande)*
nascimento | f | 27232 | 1981-04-15
+
| | | 1963-10-12
+
| | | 1971-10-30
+
| | | 1981-07-13
+
| | | 1981-09-01
+
*Depois as outras colunas:*
nome_mae | f | 39019 |
+
cidade | f | 2878 | SAO PAULO
+
estado | f | 27 | SP
+
cep | f | 33610 | 34000-000
+
regiao_fiscal | f | 10 | 8
+
*SLAVE:*
id | f | -1 |
cpf | f | -1 |
nome | f | 1.37819e+06 | MARIA APARECIDA DA
SILVA +
| | | ANA PAULA
DA SILVA +
| | | MARIA JOSE
DOS SANTOS +
| | | JOSE
ANTONIO DA SILVA +
*(lista mais alguns nomes, cortei pra não ficar muito grande)*
nascimento | f | 27230 | 1966-06-10
+
| | |
1966-10-18 +
| | |
1973-08-08 +
| | |
1975-10-20 +
*Depois as outras colunas:*
nome_mae | f | 40049 |
+
cidade | f | 2917 | SAO PAULO
+
estado | f | 27 | SP
+
cep | f | 34440 | 36880-000
+
regiao_fiscal | f | 10 | 8
+
> > 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
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
