Exatamente, são sim tabelas de "testes", geramos dados para ferramentas de pesquisa a partir de outros dados antigos... Quanto ao explain eu também já rodei sim, mas achei o modelo "correto" normalmente usando os índices conforme esperado, alías os únicos indices nessas tabelas são mesmo os que eu disse, tem um índice em set08 p/ "NUM_INST" e outro na tabela consumo para o "num_instala", apenas estes..

Na verdade nós podemos operar "fora" do banco de dados, fazer esses updates fora e depois levar para o banco, mas estavamos exatamente testando manter todas as operações no banco e esbarramos nesses tempos aí...

Já rodamos analyse sim, vaccum depois de alterações mais pesadas e etc.. o desempenho melhorou um pouco depois disso, mais ainda sim experimentamos aqueles tempos que disse no primeiro post.. mas vou experimentar rodar o analyse novamente e testar para ver..

Estou enviando o arquivo .conf hospedado no TextBin :
textbin.com/1801l

Obrigado pela atenção pessoal..






Em 30/09/2009 08:24, Jose adriano Alves < [email protected] > escreveu:


Meu amigo...
Só uma dúvida...
Que tipo de tabela é essa que vc está dando update? Não sistema real e sim testes, certo???
Outra coisa... Você já rodou um EXPLAIN para saber como está sendo feito esse update?
A pulga que está atrás da orelha é: Como assim atualizar milhões de registros??




2009/9/30 Rafael Domiciano <[email protected]>
Você poderia postar pra nós o seu arquivo .conf, assim saberemos o que foi modifcado, e também os índices dessas tabelas.

2009/9/30 Jose adriano Alves <[email protected]>

Voce ja rodou algum "analise" no banco??



2009/9/29 crgpww <[email protected]>

Olá pessoal, sou novo na lista e estamos começando a trabalhar a pouco tempo com o pg..

Estamos com um volume grande de dados e naturalmente estamos levando bastante tempo para operar com as tabelas, no entanto estamos achando que o desempenho está muito abaixo do esperado ou normal..

Situações que ilustram bem o que está acontecendo são as as seguintes atualizações...

UPDATE
  public.set08 
SET
  hcons1 = c.campo46,
  hcons2 = c.campo47,
    .
    .
    .
  hcons24 = c.set_2008_kwh
FROM
  consumo c
WHERE
  "NUM_INST" = c.num_instala;
 
Esta operação tem levado em média 20 horas sem mais nenhuma operação acontecendo em paralelo no banco... se houver o desempenho piora pra pelo menos mais 4 horas.. Nesta tabela que está sofrendo update ao todo sao 115 colunas com 5,5 milhões de registros, que representam cerca de 2,5 gb de dados num arquivo texto...

A tabela "consumo" é constiuida de 75 colunas de numeros inteiros, tem 4 milhões de registros aproximadamente, existindo um indice para num_instala. Nas tabelas que sofrem a operação, nesse caso "set08" não há indice sobre NUM_INST, com o índice o desempenho piorou em 4 horas praticamente...

O segundo update é muito mais simples mas demora demais também, cerca de 6 horas.
 
UPDATE set08
SET hcons19 = 0
where hcons19 is null;

Lendo algumas outras listas e conversando com amigos mais experientes em PG eles me sugeriram pequenas alterações no arquivo .conf, no sentido de aumentar memória e cache mas tais mudanças nao ajudaram em nada o desempenho..

O S. O. é Windows XP Professional com Sp3, e o PostgreSQL é versão 8.3... A Márquina é um Intel Core 2 Quad 2.83Ghz com 3 GB de RAM...

Vocês poderiam me dizer se estes tempos de execução estão normais? A expectativa era que o desempenho seria bem melhor.. o que poderia ser feito para melhorar?

Abraço e Obrigado, Gustavo.

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




--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  +55 44 8802 3994
Fone: + 55 44 3663 8000 - 2319
Mail: [email protected]
MSN: [email protected]



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signat ário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

_______________________________________________
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




--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  +55 44 8802 3994
Fone: + 55 44 3663 8000 - 2319
Mail: [email protected]
MSN: [email protected]



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signat ário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

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

Responder a