Re: patch : Allow toast tables to be moved to a different tablespace
Alex Shulgin <ash@commandprompt.com>
From: Alex Shulgin <ash@commandprompt.com>
To: Julien Tachoires <julmon@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>,
Jaime Casanova <jaime@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-11-28T16:38:09Z
Lists: pgsql-hackers
Attachments
- set_toast_tablespace_v0.11.patch.gz (application/gzip) patch v0
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