From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amos Bird <amosbird(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make default TABLESPACE belong to target table. |
Date: | 2016-11-28 12:49:11 |
Message-ID: | CAA4eK1KH2oCrucyhHmU1yDRRR=jrNEyVOxAGbtAwbbMzUNzqfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 26, 2016 at 9:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> What will such a storage parameter (default_tablespace) mean at table
>> level and how it will different from existing default_tablespace? I
>> think the usage asked by Amos is quite genuine, but not sure if
>> introducing default_tablespace as a storage level parameter is the
>> best way to address it. Another way could be that we allow the user
>> to specify something like tablespace_name <inherit parent>/<inherit
>> table> or something like that.
>
> That seems overcomplicated, and it will also pose quite some hazard
> for pg_dump for example. It feels like "action at a distance", in
> that creation of an index will now depend on properties that aren't
> immediately obvious.
>
> I was thinking about introducing a new GUC, named something like
> default_index_tablespace, which would need to have at least these
> behaviors:
>
> 1. index tablespace is same as default_tablespace (the backwards
> compatible, and therefore the default, behavior).
>
> 2. index tablespace is same as table's tablespace.
>
> 3. default_index_tablespace names a specific tablespace.
>
> Point 3 isn't in the current request but I'm pretty sure I've heard
> it requested in the past, so that people can conveniently put all
> tables in tablespace X and all indexes in tablespace Y.
>
> If we just did points 1 and 2 then a bool GUC would suffice. I'm
> not sure how to handle all three cases cleanly. We could define
> default_index_tablespace as empty to get point 1 or a tablespace
> name to get point 3, but that leaves us having to use some magic
> string for point 2, which would be messy --- what if it conflicts
> with someone's choice of a tablespace name?
>
Yeah, I think coming with a clean way to handle all three might be
messy. How about if just handle 2 and 3? If the table is created
with default_tablespace, then automatically it will be created in
default_tablespace. Do you think maintaining backward compatibility
is important in this case?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-11-28 13:20:53 | Re: Tackling JsonPath support |
Previous Message | Daniel Verite | 2016-11-28 12:23:12 | Re: pg_dump / copy bugs with "big lines" ? |