Olá,
Li os comentários de todos e vi que acabei criando uma pequena polemica sobre a
questão da mudança do pg_largeobject.
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.
Qual problema teria de falha/confiabilidade visto que todos os arquivos do
banco estarão no mesmo servidor, o backup seria feito do mesmo modo e o acesso
transparente aos usuarios?
O Gilnei fala de uma imprevisibilidade e de uma violação de segurança, em que
ponto isso ocorre visto que o pg_largeobject é na verdade um monte de arquivo
(com o nome OID e uma sequencia) que vai apenas mudar de local fisicamente?
[]s,
NG
________________________________
De: JotaComm <jota.c...@gmail.com>
Para: Comunidade PostgreSQL Brasileira <pgbr-geral@listas.postgresql.org.br>
Enviadas: Quarta-feira, 4 de Março de 2009 9:25:51
Assunto: Re: [pgbr-geral] Como alterar a tablespaces do pg_largeobject?
Olá, pessoal
Ontem eu fiquei pensando bastante sobre essa questão de mudar a
pg_largeobject para um outro lugar usando o recurso de tablespace.
Pensei, pensei e não cheguei a conclusão de qual seria a vantagem
disso. E me fiz a seguinte pergunta: Qual a grande vantagem de fazer
essa modificação? Performance? Organização/distribuição das tabelas e
índices para melhorar o layout? Se for relacionado a performance não
acredito que isso não trará ganhos absurdos de performance. Se for
para melhorar o layout irei misturar tabelas de sistema com tabelas de
usuário e sinceramente não acredito que isso seja uma boa prática. Ai
faço outra pergunta: Por que não deixar o catálogo onde está e
trabalhar com o recurso de tablespace para as tabelas/índice do
usuário?
Fiquem a vontade para comentários.
[]s
2009/3/4 Euler Taveira de Oliveira <eu...@timbira.com>:
> Gilnei M. Oliveira escreveu:
>> primeira questão deve ser sempre confiabilidade do conjunto...
> O que tem a ver confiabilidade? Estamos falando da possibilidade de colocar um
> catálogo *não-crítico* em um outro local.
>
>> de nada
>> adianta reduzir os tempos de acesso em hardware se pode-se introduzir
>> no mecanismo de controle uma possibilidade maior de falha...
> Falha? Não vejo como um catálogo que *não* requer um tratamento especial
> falharia; pg_largeobject é uma mera tabela, só que faz parte do catálogo.
>
>> você estaria sozinho nesta parada... isto é muito gratificante para quem
>> é um pioneiro desenvolvedor, mas é uma catástrofe para quem tem a tarefa
>> de manter o banco no ar...
> Se eu propus uma solução é porque verifiquei que não teria maiores problemas.
>
>> e aparentemente a mudança nunca foi incluída
>> como prioridade simplesmente porque o beneficio obtido não supera os custos
>> de desenvolvimento neste item...
>>
> Ugh? Um simples teste ao alterar uma tablespace não é difícil. IMHO isso não
> foi feito ainda porque ninguém propos um patch.
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
--
JotaComm
http://jotacomm.wordpress.com
http://www.dextra.com.br/Postgres
_______________________________________________
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