Julien Tachoires <jul...@gmail.com> writes:
> 2011/12/15 Alvaro Herrera <alvhe...@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


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:


Should I add this patch to the next CommitFest?


Attachment: set_toast_tablespace_v0.11.patch.gz
Description: application/gzip

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to