Bregnoles

Obrigado Ronivaldo! Tenho um outro assunto, você já se deparou com esse erro na hora de migrar o Postgresql 8.3 para Postgresql 9.3? Estou utilizando o comando pg_upgrade.exe, ele apresenta esse erro: You will need to rebuild the new server with configure option --disable-integer-datetimes or get server binaries built with those options. Isso se refere a formato de armazenamento de data-hora que não é compatível. Rodei o pg_controldata na base de dados 8.3 mostra o tipo de data/hora numeros de pontos flutuantes na base 9.3 mostra inteiros de 64 bits. Como posso arrumar isso já que esse formato não corresponde nas duas bases utilizando o pg_upgrade? Aguardo seu retorno! Obrigado!

Boa tarde, Estou com um problema em um cliente que quando realizar o backup pg_dump em alguns caso apresenta esse erro de LOG: pg-dump: Cópia do conteúdo da tabela "ihistcomercial_log" falhou: PQgetCopyData() falhou: pg_dump: Mensagem de erro do servidor: perda de sincronismo com o servidor: recebeu tipo de mensagem "d", tamanho 729 Alguém tem alguma ideia sobre porque ocorre esse erro? Isso sempre ocorre nessa tabela ihistcomercial_log ela está com tamanho de 730.000 mil registros. Aguardo! att Oswaldo

Ronivaldo, Boa tarde, estou querendo atualizar o postgres de 8.3 para 9.3, estou utilizando o pg_upgrade pg_upgrade.exe --old-datadir "C:/Arquivos do Programa/PostgreSQL/oldVersion/data" --new-datadir "C:/Program Files/PostgreSQL/newVersion/data" --old-bindir "C:/Arquivos do programa/PostgreSQL/oldVersion/bin " --new-bindir "C:/Program Files/PostgreSQL/newVersion/bin" - Só que está apresentado esse erro: você poderia me dizer o que eu tenho que fazer para corrigir isso? Erro apresentados. #mapped win32 error code 2 to 2 Old and new pg_controldata date/time storage types do not match. #You will need to rebuild the new server with configure option --disable-integer-datetimes or get server binaries built with those options. Tradução: Você precisará reconstruir o novo servidor com opção de configuração -desativar-desabilitar datas de inteiros ou obter binários de servidor construídos com aqueles Opções

Boa tarde! Gostaria de saber, no configurador do postgresql.conf tem alguns parametros no menu QUERY TUNING: são esses: # - Planner Method Configuration - #enable_bitmapscan = on #enable_hashagg = on #enable_hashjoin = on #enable_indexscan = on #enable_mergejoin = on #enable_nestloop = on #enable_seqscan = on #enable_sort = on #enable_tidscan = on # - Planner Cost Constants - #seq_page_cost = 1.0 # measured on an arbitrary scale #random_page_cost = 2.0 # same scale as above Se eu descomentar, isso é ativá-los, podemos dizer que isso pode melhorar a performance dos meus select com grande quantidade de dados sequenciais por Index ou por PK? Por gentileza, o que eu quero saber é: Esses parâmetros qual é sua finalidade em questão de melhoria na performance em selects de tabelas grandes, com join, hash, etc? Fico no aguardo! Obrigado!

Olá Ronivaldo, Conforme voce falou eu fiz isso: temp_tablespaces = 'F:/tmp_tablespace/' - alterei parametro do postgres.conf direcionando para outro disco e rodei esses comandos: CREATE TABLESPACE dbspace_tmp LOCATION 'F:/tmp_tablespace'; CREATE DATABASE dbspace_tmp tablespace dbspace_tmp; ALTER DATABASE "my_db" SET temp_tablespaces = dbspace_tmp; Isso já identifica que vou usar as tabelas temporária do meu banco de dados vão usar essas tabelas temporárias em outro disco. O padrão da tbspc é no local padrão onde está instalado o postgres. Como esse procedimento ele vai direcionar para essa nova tbspc? Tem mais alguma coisa a se fazer para melhorar a performance do postgres, voce comentou sobre criar disco virtual utilizando parte da memória RAM, como é feito isso? Obrigado!

Outra coisa que observei, é que quando você executa pela primeira vez ele na opção 2, o processamento não é tão bom mas depois que ele armazena na memória os próximos processamento melhora muito. O que você me diz sobre isso? obrigado Ronivaldo!

Bom dia, Ronivaldo, Somente uma pergunta: Estamos fazendo uma análise pra melhorar a performance do postgres na utilização de index ou PK nos SELECTS, com todos esses levantamento de teste, qual seria a melhor apção: 1 - enable_indexscan = off e enable_seqscan = on ou 2 - enable_indexscan = on e enable_seqscan = off ou 3 - enablea_indexscan = off e enable_seqscan = off ou 4 - enablea_indexscan = on e enable_seqscan = on Fiz alguns testes com PK e com index e somente com index exemplo: EXPLAIN ANALYZE select * from histcomercial, entidades where histcomercial.co_entidades = '182' and entidades.co_categoria = '2'; os dois campos são index, utilizando a opção 1 tive um ganho de 18% na performance, seria então a opção 1 a melhor opção?

Boa tarde, Ronivaldo Essa alteração de configuração no postgres. Isso pode afetar alguma outra transação do postgres? Deixando lento em outros processos? Agurado e Obrigado!

Por gentileza, Verificando pelo Explain query do analyze do Postgres, de um SELECT * FROM ..., vejo que em algumas tabelas pequenas ele não usa a PK como regra de index. Alguém poderia me dizer se isso ocorre e qual é o motivo? E até quantos registros tem a tabela para ele considerar e usar pesquisa sequencial ou pela PK ou índice? Obrigado!