Muito obrigado. Já conseguimos colocar no ar o procedimento.
Att
Paulo Bastos
Em 27/06/2013 22:12, gilmarli...@agrovale.com.br escreveu:Não.O Ip virtual só fica no host primário.Caso o host primario cair o ip e migrado para o outro servidor.O haresources deve ser identicos nas duas
2013/6/28 Paulo Bastos prbalme...@bol.com.br
Muito obrigado. Já conseguimos colocar no ar o procedimento.
Só uma dica. Já que está começando, evite usar o Heartbeat, e parta pra
dupla Pacemaker+Corosync, pois o desenvolvimento do Pacemaker está ativo e
do Heartbeat parado.
Atenciosamente,
--
Em 27 de junho de 2013 12:28, Marcelo Henrique Gonçalves billm...@gmail.com
escreveu:
Seu problema não parece de tuning da instância PostgreSQL e sim de
arquitetura.
Estude redução dos índices, melhor where clause para o update, FKs que
apontam para a PK dessa, etc...
2013/6/27 Douglas
Caros,
Meu Windows corrompeu e eu não estou conseguindo fazer a restauração. Tenho
todos meus arquivos guardados em outra unidade, por isso, a unica solução é
mesmo formata-lo. Mas, lembrei que os arquivos de Data do Banco estão no
disco C. Com o CD do Ubuntu(Linux), consegui visualizar a pasta
Em 28 de junho de 2013 09:09, Marcel Farias Costa
marcelffar...@gmail.comescreveu:
Caros,
Meu Windows corrompeu e eu não estou conseguindo fazer a restauração.
Tenho todos meus arquivos guardados em outra unidade, por isso, a unica
solução é mesmo formata-lo. Mas, lembrei que os arquivos de
2013/6/28 Douglas Fabiano Specht douglasfabi...@gmail.com
Em 27 de junho de 2013 12:28, Marcelo Henrique Gonçalves
billm...@gmail.com escreveu:
Seu problema não parece de tuning da instância PostgreSQL e sim de
arquitetura.
Estude redução dos índices, melhor where clause para o update,
Bom dia!
Hoje me deparei com um método que cria uma série de Temp Table e como a
carga é bem grande nas mesmas, é criado também Indices...
O método tem uma performance bem baixa, eu percebi que os Índices na Temp
Table aumentam um pouco a performance do método, porém gostaria de saber se
Gostaria de lembrar que não estamos falando de Oracle, que usa UNDO e não
precisa tocar nos outros índices.
Estamos falando de MVCC e de suas tuplas.
https://devcenter.heroku.com/articles/postgresql-concurrency
Ler:
Disadvantages of
Em 28-06-2013 10:02, João Paulo Rieg escreveu:
Bom dia!
Hoje me deparei com um método que cria uma série de /Temp Table /e como
a carga é bem grande nas mesmas, é criado também Indices...
Procure criar os índices depois da carga. É bem mais rápido.
O método tem uma performance bem baixa,
bom dia Pessoal,
estive analisando e testando alguns updates, e pude verificar que se
deixar a tabela com 50 campos, a performance do update melhora em de uns
20min para 7min.
Isso depende das colunas que você retirou. Quanto maiores as colunas,
maior a diferença.
dropando os indices
Em 28-06-2013 10:02, João Paulo Rieg escreveu:
Bom dia!
Hoje me deparei com um método que cria uma série de /Temp Table /e
como a carga é bem grande nas mesmas, é criado também Indices...
Procure criar os índices depois da carga. É bem mais rápido.
Beleza!
O método tem uma performance bem
Então simulando uma ocorrência de uso, eu vou estar fazendo o seguinte:
Abrindo a seção;
Criando a TempTable;
Carregando os dados;
Criando Indices;
Faço um analyse nas temp tables;
Executo os updates e Selects necessários;
Gravo os dados necessários em tabelas Fixas;
Encerro a seção; (que vai
Concordo com todas as afirmações do Flavio.
Só quis lembrar que no Oracle, a linha vai para UNDO e somente quando a
linha precisa mudar de ROWID os índices são atualizados (no caso de coluna
não indexada).
No update do PostgreSQL SEMPRE os índices serão atualizados de qualquer
forma.
Quando disse
Em 28-06-2013 12:12, Marcelo Henrique Gonçalves escreveu:
Concordo com todas as afirmações do Flavio.
Só quis lembrar que no Oracle, a linha vai para UNDO e somente quando a
linha precisa mudar de ROWID os índices são atualizados (no caso de
coluna não indexada).
No update do PostgreSQL SEMPRE
Obrigado pela correção! Realmente palavra 'sempre' não deveria estar ali :).
O Flavio põe muito bem a implementação do HOT e é importante ter isso em
mente pois é uma otimização de grande impacto no MVCC.
Mas voltando ao caso do nosso colega, acho que no caso dele os índices
estão sendo
Em 28 de junho de 2013 13:16, Marcelo Henrique Gonçalves billm...@gmail.com
escreveu:
Obrigado pela correção! Realmente palavra 'sempre' não deveria estar ali
:).
O Flavio põe muito bem a implementação do HOT e é importante ter isso em
mente pois é uma otimização de grande impacto no MVCC.
Em 28-06-2013 13:36, Douglas Fabiano Specht escreveu:
boa tarde Pessoal,
obrigado pelas resposta, fiz os testes nessa tabela com e sem indices e
vejam o resultado:
--sem indices
UPDATE LANCCAIXA2 SET FLINDPAG = 2 --Query returned successfully:
1413418 rows affected, 75188 ms execution time.
Em 28 de junho de 2013 13:50, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 28-06-2013 13:36, Douglas Fabiano Specht escreveu:
boa tarde Pessoal,
obrigado pelas resposta, fiz os testes nessa tabela com e sem indices e
vejam o resultado:
--sem indices
UPDATE LANCCAIXA2
Fique atento que com o crescimento da tabela o sort pode passar a ser feito
em disco demorando e impactando o IO da máquina.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
19 matches
Mail list logo
