Fiz um teste com tabela paritcionada
http://www.postgresql.org/docs/current/static/ddl-partitioning.html
Os check são por data e ele cria o indice para o campo logdate CREATE
INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate); até
aqui tudo ok.
Mas se eu crio um indice para o
2010/3/26 mateusgra :
>
> Tabelas grandes são armazenadas como múltiplos arquivos de 1 GB conforme:
> http://www.postgresql.org/docs/faqs.FAQ_brazilian.html#item4.4
>
> Aumentar o tamanho desse arquivo aumenta o desempenho ?
>
> Onde aumenta o tamnho padrão desse arquivo no postgresql 8.2 ?
A par
Olá,
2010/3/26 JotaComm
> Olá,
>
> 2010/3/26 mateusgra
>
>
>> Tabelas grandes são armazenadas como múltiplos arquivos de 1 GB conforme:
>> http://www.postgresql.org/docs/faqs.FAQ_brazilian.html#item4.4
>>
>> Aumentar o tamanho desse arquivo aumenta o desempenho ?
>>
>
> Não vejo motivo para iss
Olá,
2010/3/26 mateusgra
>
> Tabelas grandes são armazenadas como múltiplos arquivos de 1 GB conforme:
> http://www.postgresql.org/docs/faqs.FAQ_brazilian.html#item4.4
>
> Aumentar o tamanho desse arquivo aumenta o desempenho ?
>
Não vejo motivo para isso.
>
> Onde aumenta o tamnho padrão dess
Tabelas grandes são armazenadas como múltiplos arquivos de 1 GB conforme:
http://www.postgresql.org/docs/faqs.FAQ_brazilian.html#item4.4
Aumentar o tamanho desse arquivo aumenta o desempenho ?
Onde aumenta o tamnho padrão desse arquivo no postgresql 8.2 ?
--
View this message in context:
htt
OK, vamos lá.
2010/3/26 Pablo Sánchez
> Só para acrescentar e matar a minha curiosidade: qual é o dispositivo
> que está travando? Será que ele não pode ser posicionado em outro
> local, onde sofra menos interferência?
>
>
Trabalhamos a uns 3 anos no desenvolvimento de um sistema de aquisição de
Caro Thiago, boa tarde.
Sou usuário do PostgreSQL desde a versão 7.1, mas, acredito que o
Firebird seria uma solução melhor para o seu tipo de aplicação. Há algum
tempo ouvi que o sistema utilizado em tanques de guerra norte americanos
enfrentava um problema similar ao seu e resolveram utiliza
humm... vou tentar
Em 26 de março de 2010 15:28, Everson Barbosa escreveu:
> Alipio,
>>
>
> Você tentou fazer sem utilizar as ' vírgulas ' ?
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.b
>
> Alipio,
>
Você tentou fazer sem utilizar as ' vírgulas ' ?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>From Josh Berkus
I hereby declare Saturday, April 3, PostgreSQL Test-Fest day. Get our
your computers and get ready to test Version 9.
We need *you* to spend a full day testing Postgres 9 in order to
complete the Alpha/Beta testing period on time and release 9.0 as
scheduled. Without your help
Em 26 de março de 2010 12:09, JotaComm escreveu:
> Olá, Fabrízio
>
> Blz?
>
>
Grande Jota!!!
Fora a correria natural na nossa profissão (rsrs), tudo na paz!!!
> Se a minha memória não falha o Léo Cezar uma vez teve este problema com
> isso na época em que trabalhávamos juntos, porém eu não pa
Olá, Fabrízio
Blz?
Em 26 de março de 2010 12:03, Fabrízio de Royes Mello <
fabriziome...@gmail.com> escreveu:
> Pessoal,
>
> Recentemente em um cliente tive o problema de uma sequence "pular" o valor
> 32 por duas vezes... dando uma olhada na mesma pude observar que o valor da
> coluna "log_cnt"
Pessoal,
Recentemente em um cliente tive o problema de uma sequence "pular" o valor
32 por duas vezes... dando uma olhada na mesma pude observar que o valor da
coluna "log_cnt" está 32:
base=# select * from protocolo.protprocesso_p58_codproc_seq ;
sequence_name | last_value | incr
utiliza a 8.4
Em 26 de março de 2010 11:35, Osvaldo Kussama
escreveu:
> Em 26 de março de 2010 10:59, Alipio Dantas
> escreveu:
> > Srs.
> >
> > Minha intenção é fazer o dump de alguns schemas e não do banco todo
> >
> > utilizei:
> >
> > $ORIGEM/pg_dump --inserts -h 10.56.1.1 -U postgres
Em 26 de março de 2010 10:59, Alipio Dantas escreveu:
> Srs.
>
> Minha intenção é fazer o dump de alguns schemas e não do banco todo
>
> utilizei:
>
> $ORIGEM/pg_dump --inserts -h 10.56.1.1 -U postgres -f
> $DESTINO/$DATA-bd_sedur_schemas.sql -n 'auxiliar_dados_gerais', -n
> 'aguas_urbanas'
Srs.
Minha intenção é fazer o dump de alguns schemas e não do banco todo
utilizei:
$ORIGEM/pg_dump --inserts -h 10.56.1.1 -U postgres-f
$DESTINO/$DATA-bd_sedur_schemas.sql -n 'auxiliar_dados_gerais', -n
'aguas_urbanas', -n 'notas_tecnicas', -n 'pac', -n 'pleitos', -n 'public',
-n 'sentin
Só para acrescentar e matar a minha curiosidade: qual é o dispositivo
que está travando? Será que ele não pode ser posicionado em outro
local, onde sofra menos interferência?
Em 25 de março de 2010 12:28, Thiago Tiedtke dos Reis
escreveu:
> Bom dia pessoal,
>
> Acompanho a lista a muito tempo, e
Em 25 de março de 2010 18:28, Osvaldo Kussama
escreveu:
>
> Creio que o ponto principal seja: Não é possível trocar o sistema
> operacional para outro mais confiável?
Verdade, há diversos OSs que seriam mais confiáveis. Mas o problema é
que mesmo trocando o OS ainda existe a questão do isolamento
Você pode desabilitar o fsync, que é o sincronimo automático com o
filesystem. Mas aí, você corre o risco de perda de dados, só que você
tem que pensar no custo-benefício: melhor perder alguns dados do que
TODOS os dados.
Você deu uma olhada no SQLite? Acho que é um banco mais leve para
sistemas e
Em 25 de março de 2010 22:49, Tiago Adami escreveu:
> Verifique nas contas de usuário se existe uma conta do usuário
> postgres e remova. Se você está instalando em uma máquina dentro de um
> domínio, peça para o administrador da rede alterar a senha do usuário
> postgres no domínio e lhe informar
20 matches
Mail list logo
