Julien Tachoires <julmon@gmail.com> writes:
>
> 2011/12/15 Alvaro Herrera <alvherre@commandprompt.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? =A0Just pass down the toast tablespace into
>> AlterTableCreateToastTable, instead of having it assume that
>> rel->rd_rel->relnamespace is sufficient. =A0This 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 creat=
> ion
> - to keep it previous tablespace in case of recreation.
>
> Here's a new version rebased against HEAD.
Almost 3 years later, here's a version rebased against current HEAD. :-)
It compiles and even passes the included regression test.
There were doubts originally if this is actually a useful feature, but
there is at least one plausible use case (main table on SSD, TOAST on
HDD):
http://www.postgresql.org/message-id/4F3267EE.80405@deltasoft.no
I didn't add anything on top of the latest version, but I notice we've
added mat. views since then, so it looks like we now also need this:
ALTER MATERIALIZED VIEW SET [VIEW | TOAST] TABLESPACE
Should I add this patch to the next CommitFest?
--
Alex
