Re: make default TABLESPACE belong to target table.
От | Amit Kapila |
---|---|
Тема | Re: make default TABLESPACE belong to target table. |
Дата | |
Msg-id | CAA4eK1KH2oCrucyhHmU1yDRRR=jrNEyVOxAGbtAwbbMzUNzqfQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: make default TABLESPACE belong to target table. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: make default TABLESPACE belong to target table.
|
Список | pgsql-hackers |
On Sat, Nov 26, 2016 at 9:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapila16@gmail.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
В списке pgsql-hackers по дате отправления: