Olá Esta é uma questão correlacionada a diversas discussões ocorridas na pgsql-hackers(at)postgresql(dot)org... não me parece que a modificação e violação de security policies em relação ao pg_largeobject compense a imprevisibilidade que vai se introduzir no conjunto do dbms... pois a primeira questão deve ser sempre confiabilidade do conjunto... de nada adianta reduzir os tempos de acesso em hardware se pode-se introduzir no mecanismo de controle uma possibilidade maior de falha... lembre que 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... 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...
um abraço e boa sorte gilnei PS: e se mesmo assim fizer as alterações lembre de compartilhar os experimentos... todo mundo vai gostar de saber... :-) Em 03/03/09, Euler Taveira de Oliveira<eu...@timbira.com> escreveu: > Nelson Gonzaga escreveu: > > Criei varias tablespaces e estou querendo separar tabelas, indices e lo > > em vários HD do servidor, porem não estou conseguindo mudar a tablespace > > do pg_largeobject com o comando abaixo: > > > > alter table pg_largeobject set tablespace tbs_lo; > > > Para que você quer fazer isso? pg_largeobject é um catálogo do sistema que > armazena a estrutura de um LO. Você não precisa separar o catálogo em outras > tablespaces (alguns deles nem podem ser movidos); nunca vi ninguém reclamar > de > problemas de performance com relação ao catálogo mas talvez o pg_largeobject > seja um futuro candidato para retirarmos essa restrição. > > > dá o seguinte: > > ERROR: permission denied: "pg_largeobject" is a system catalog > > > > Tem algum jeito de driblar esta permissão? > > > Tem. [Rápida olhada no código...] Aparentemente não há problemas mas eu > sugiro > fazer uma série de testes para não ser pego de surpresa. Inclusive isso já > foi > sugerido [1] mas até agora ninguém fez. > > $ postgres --single -O -D /data > > PostgreSQL stand-alone backend 8.4devel > backend> create tablespace tbs_lo location '/tmp/tbs_lo'; > backend> alter table pg_largeobject set tablespace tbs_lo; > backend> ^D > > psql (8.4devel) > Type "help" for help. > > euler=# \dS pg_largeobject > Tabela "pg_catalog.pg_largeobject" > Coluna | Tipo | Modificadores > --------+---------+--------------- > loid | oid | not null > pageno | integer | not null > data | bytea | > Índices: > "pg_largeobject_loid_pn_index" UNIQUE, btree (loid, pageno) > Tablespace: "tbs_lo" > > > [1] http://archives.postgresql.org/pgsql-hackers/2004-06/msg00841.php > > > > -- > 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 > -- (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
