Re: Move vs. copy table between databases that share a tablespace?
От | Ron |
---|---|
Тема | Re: Move vs. copy table between databases that share a tablespace? |
Дата | |
Msg-id | 1e17699e-de0a-6a5f-9bed-64de27335099@gmail.com обсуждение исходный текст |
Ответ на | Re: Move vs. copy table between databases that share a tablespace? (Steven Lembark <lembark@wrkhors.com>) |
Ответы |
Re: Move vs. copy table between databases that share a tablespace?
|
Список | pgsql-general |
On 4/3/19 8:39 AM, Steven Lembark wrote: > On Wed, 3 Apr 2019 08:33:54 -0500 > Ron <ronljohnsonjr@gmail.com> wrote: > >> On 4/3/19 8:18 AM, Steven Lembark wrote: >>> Trying to find a way of moving a large table between databases >>> in the same cluster. There is not sufficient space to copy the >>> contents -- the dedicated tablespace that fits the beastie is >>> on an 80% full disk. >>> >>> Given that the two databases live in the same cluster and have >>> the owner & the tablespace in common, is there any way to move >>> the contents without a dump & reload? >> COPY TO STDIN and pipe that through ssh to another server? > That makes a copy. There is no place to store two copies of the > full data on disk. Through a pipe to a different server. > I'm basically trying to perform the moral equivalent of what "mv" > does in the filesystem: re-link the inode and remove the old inode > without duplicating the data. > > Since the tablespace is visible to both I would get that there is > some way to alter table... that allocates the space on disk to the > new database w/o having to unload all 400M rows -- if it comes down > to that I'll have to copy it into xz and load it back in the new > database. > -- Angular momentum makes the world go 'round.
В списке pgsql-general по дате отправления: