| From: | Euler Taveira <euler(at)timbira(dot)com(dot)br> |
|---|---|
| To: | Andreas Joseph Krogh <andreas(at)visena(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods. |
| Date: | 2016-10-18 14:26:37 |
| Message-ID: | 9c0f30fb-80a5-40de-9ce8-1f92d6380ac7@timbira.com.br |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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, Suporte 24x7 e Treinamento
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-10-18 14:40:55 | Re: Query cancel seems to be broken in master since Oct 17 |
| Previous Message | Tom Lane | 2016-10-18 14:03:39 | Re: Query cancel seems to be broken in master since Oct 17 |