Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods. - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.
Date
Msg-id 9c0f30fb-80a5-40de-9ce8-1f92d6380ac7@timbira.com.br
Whole thread Raw
In response to Move pg_largeobject to a different tablespace *without* turning on system_table_mods.  (Andreas Joseph Krogh <andreas@visena.com>)
Responses Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.  (Andreas Joseph Krogh <andreas@visena.com>)
List pgsql-hackers
On 18-10-2016 10:13, Andreas Joseph Krogh wrote:
> From time to time pg_largeobject comes up as an issue with being
> implemented as a system-catalog.
>  
Did you read the archives [1]?

> As I see it, there are 2 relevant use-cases for improving the situation:
> 1. Being able to pg_dump *without* any LOs (think of it as
>    without the contents of pg_largeobject). This is very handy
>    for testing/troubleshooting.
>
It could be an option (--no-blobs). The -b option has a limited use case.

> 2. Being able to move pg_largeobject to a different tablespace
>    *without* turning on system_table_mods. This is important for
>    people storing LOTS of large-objects on separate
>    disks (non-SSD) and hence in a different tablespace.
> Anyone willing to discuss this?
>  
This was proposed a few years ago but no one cared to draft a patch.


[1]
https://www.postgresql.org/message-id/3073cc9b0910051618t693d15f3u265872908240d306@mail.gmail.com


--   Euler Taveira                   Timbira - http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query cancel seems to be broken in master since Oct 17
Next
From: Tom Lane
Date:
Subject: Re: Query cancel seems to be broken in master since Oct 17