Re: patch : Allow toast tables to be moved to a different tablespace

On Wed, Jan 25, 2012 at 7:13 AM, Julien Tachoires <julmon(at)gmail(dot)com> wrote:
> 2012/1/24 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Sun, Jan 22, 2012 at 11:04 AM, Julien Tachoires <julmon(at)gmail(dot)com> wrote:
>>> 2011/12/15 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>>>>
>>>> Uhm, surely you could compare the original toast tablespace to the heap
>>>> tablespace, and if they differ, handle appropriately when creating the
>>>> new toast table?  Just pass down the toast tablespace into
>>>> AlterTableCreateToastTable, instead of having it assume that
>>>> rel->rd_rel->relnamespace is sufficient.  This should be done in all
>>>> cases where a toast tablespace is created, which shouldn't be more than
>>>> a handful of them.
>>>
>>> Thank you, that way seems right.
>>> Now, I distinguish before each creation of a TOAST table with
>>> AlterTableCreateToastTable() : if it will create a new one or recreate
>>> an existing one.
>>> Thus, in create_toast_table() when toastTableSpace is equal to
>>> InvalidOid, we are able :
>>> - to fallback to the main table tablespace in case of new TOAST table creation
>>> - to keep it previous tablespace in case of recreation.
>>>
>>> Here's a new version rebased against HEAD.
>>
>> To ask more directly the question that's come up a few times upthread,
>> why do *you* think this is useful?  What motivated you to want this
>> behavior, and/or how do you think it could benefit other PostgreSQL
>> users?
>
> Sorry, I didn't get this question to me. I've just picked up this item
> from the TODO list and then I was thinking that it could be useful. My
> motivation was to learn more about PostgreSQL dev. and to work on a
> concrete case. Now, I'm not sure anymore this is useful.

OK. In that case, I don't think it makes sense to add this right now.
I share the feeling that it could possibly be useful under some set
of circumstances, but it doesn't seem prudent to add features because
there might hypothetically be a use case. I suggest that we mark this
patch Returned with Feedback and add links to your latest version of
this patch and one of the emails expressing concerns about the utility
of this patch to the Todo list. If we later have a clearer idea in
mind why this might be useful, we can add it then - and document the
use case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company