Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

From: Andreas Joseph Krogh <andreas(at)visena(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.
Date: 2016-10-19 16:57:28
Message-ID: VisenaEmail.8e.37d8b22bb9c2a095.157ddda1e2a@tc7-visena
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

På onsdag 19. oktober 2016 kl. 18:44:24, skrev Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
<mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>>:
Andreas Joseph Krogh <andreas(at)visena(dot)com> writes:
> På onsdag 19. oktober 2016 kl. 18:29:31, skrev Bruce Momjian
<bruce(at)momjian(dot)us
>  I think an open question is why you would not want to move the other
>  system tables at the same time you move pg_largeobject.

> Are you saying that if I move all system-tables to the tablespace I moved
> pg_largeobject to it'll work? If so, is there a convenient way to move all
> system-tables to a tablespace?

Not sure about moving them after the fact, but you could create the
database with its default tablespace being the one you want pg_largeobject
in.

I think though that there's a fairly clear counterexample to Bruce's
question: if you're worried about moving pg_largeobject at all, you
probably are trying to put it on a relatively large and slow storage
device.  You don't necessarily want all the system catalogs there.

regards, tom lane
 
Thanks for the tip. How do I conveniently move all the
tables/indexes/sequences etc. (basically everything in schema=public) except
the system-tables to another tablespace?
I don't see any "ALTER SCHEMA public SET TABLESPACE myspace" command...
 
This is great when dealing with new databases, but do you have any hints
helping me out getting pg_upgrade working now that I already have moved
pg_largeobject (see my answer to Bruce)?
 
Thanks.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>
www.visena.com <https://www.visena.com>
<https://www.visena.com>

 

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2016-10-19 16:58:05 Re: Indirect indexes
Previous Message Claudio Freire 2016-10-19 16:55:39 Re: Indirect indexes