Skip site navigation (1) Skip section navigation (2)

Re: ALTER SCHEMA ... SET TABLESPACE

From: maurizio(dot)totti(at)gmail(dot)com
To: pgsql-it-generale(at)postgresql(dot)org
Subject: Re: ALTER SCHEMA ... SET TABLESPACE
Date: 2008-11-18 14:21:37
Message-ID: a86f58d90811180621p197265cat64094f03c2dd76ef@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-it-generale
Il 18 novembre 2008 14.14,  <rotellaro(at)gmail(dot)com> ha scritto:
>
> Probabilmente si sono resi conto che non serviva a niente visto che
> queste cose si fanno con dei banali concatenamenti di stringa.
>
Dici?... mah certo che è strano, non capisco bene come vengano gestite
in pg_catalog queste cose. Per esempio se decidi di creare un
tablespace separato e ci crei un db tutti gli oggetti che poi crei in
quel db finiscono in quella porzione del fs, ma se cerchi in pg_class
(o in pg_tables e altro se preferisci) trovi valorizzata come
tablespace la pg_global o niente (reltablespace 0)

Se invece guardi come fa pgadmin3 a capire gli oggetti che dipendono
da un tablespace scopri che "alla fine" o comunque sulla mia
installazione pg 8.3.5 e pgadmin3 1.8.4 lo recupera dagli oggetti che
"appartengono" al db che insiste su quel tablespace (in pg_database il
dattablespace è correttamente valorizzato)

Tutto questo per dire che mi chiedevo se fosse possibile gestire
l'allocazione di un intero schema su di un tablespace separato questo
per non dover successivamente migrare indici e tabelle e magari avere
già le sequence (o se è possibile altro) che non sono migrabili nel
posto giusto.
Anche perché apparentemente nell strutture del pg_catalog i dati dei
tablespace potrebbero essere valorizzati.

Ciao.

-- 
Maurizio Totti
socio ITPUG http://www.itpug.org

In response to

pgsql-it-generale by date

Next:From: Gianni CiolliDate: 2008-11-21 18:56:27
Subject: == Notiziario settimanale PostgreSQL, 16 novembre 2008 ==
Previous:From: rotellaroDate: 2008-11-18 13:14:43
Subject: Re: ALTER SCHEMA ... SET TABLESPACE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group