Caro Gilnei,
O meu grande medo de continuar do jeito que está, isto é, o pg_catalog todo
junto, é a tabela pg_largeobject crescer demais e estourar a capacidade do
HD(está longe disso ainda, mas...) ai as outras tabelas do catalogo que
realmente sao importantes ficam sem espaço e o meu sistema buuuuuummmmmmmm.
Vou continuar pesquisando e qualquer novidade eu posto aqui.
Agradeco a todos a atençao dispensada,
NG
________________________________
De: Gilnei M. Oliveira <ogil...@gmail.com>
Para: Comunidade PostgreSQL Brasileira <pgbr-geral@listas.postgresql.org.br>
Enviadas: Quarta-feira, 4 de Março de 2009 12:19:04
Assunto: Re: [pgbr-geral] Res: Como alterar a tablespaces do pg_largeobject?
Oi
Nelson
Ohhh!! Puxa, o teu problema não é o catalogo e sim o vertiginoso crescimento
de lobs...
Imediatamente surgem dois pontos:
1) O problema é Performance: RAID é a solução mais barata para isto...
2) O problema é o Tamanho: RAID ajuda, mas não resolve...
Se isto está impactando sobre as rotinas de backup o melhor é uma sólida
politica de descarte seja físico ou lógico... físico é fácil >>
\dev\null, lógico:
bem aí podes começar colocando os dados de uso menos frequente em
discos mais lentos, mantendo apenas o que realmente está em uso nos
discos rápidos... isto é muito melhor que quebrar o catálogo... e por aí
vai até chegar a um nearline storage ou pura e simples recuperação de
arquivos de backup via solicitação a um bot automático ou manual...
O mais importante é que não se pode guardar todos os lobs num monólito, pois
isto é um problema exponencial...
bye
gilnei
Em 04/03/09, Nelson Gonzaga<ngonz...@yahoo.com> escreveu:
>
> O sistema desenvolvido aqui é um GED que guarda os dados de um documento
> (nome, data e outras caracteristicas) e o proprio documento(.doc, .xls,
> .pdf) no pg_largeobject, como este cresce *igual um louco*, mesmo fazendo
> vaccum, pensei em colocar um HD só pra ele.
>
> A minha ideia inicial é criar 3 tablespaces(um para as tabelas, outro para
> os indices/constraints e outro para o *famigerado* lo), com o intuito de
> separar estes em HDs diferentes e acelerar o processo de leitura/gravacao,
> aumentando a performance (e talvez a confiabilidade) pois como disse o
> Euler: a pg_largeobject é uma mera tabela, só que faz parte do catálogo.
>
--
(pt_BR; ogil...@gmail.com)
E9BA2383; wwwkeys.pgp.net
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
