Re: make default TABLESPACE belong to target table.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
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-26 16:16:46
Message-ID: 12920.1480177006@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-26 16:25:14 Wrong order of tests in findDependentObjects()
Previous Message Tom Lane 2016-11-26 16:06:26 Re: Skipping PgStat_FunctionCallUsage for many expressions