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<[email protected]> 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; [email protected])
E9BA2383; wwwkeys.pgp.net
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
