Re: Updated ALTER TABLE ... SET TABLESPACE patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Updated ALTER TABLE ... SET TABLESPACE patch
Date: 2004-07-12 02:36:51
Message-ID: 3777.1089599811@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Will toast go in the same tablespace as the base table?

That is the current design, and I'd prefer to keep it that way because
anything else adds great complexity for unclear gain.

Two examples of pain points:

1. That pending patch to report a table's tablespace in psql \d would
get lots more complex: you'd have up to three tablespaces to worry about
(base table, toast table, toast index).

2. How would pg_dump restore such a setup? It could not generate a
script that says ALTER TABLE pg_toast.pg_toast_NNN SET TABLESPACE,
because it has no way to know what NNN should be. I think we'd have
to add locutions like "ALTER TABLE foo SET TOAST TABLESPACE t" and
"ALTER TABLE foo SET TOAST INDEX TABLESPACE t" to do this in a clean
fashion.

In fact, now that I think of it, the patch-as-committed already
introduces some serious headaches for pg_dump: it can't know for sure
what name will be assigned to constraint indexes (pkey and unique
indexes) so it has no good way to emit ALTER TABLE SET TABLESPACE
commands for those indexes.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-07-12 02:54:06 Re: Updated ALTER TABLE ... SET TABLESPACE patch
Previous Message Gavin Sherry 2004-07-12 02:28:52 Re: Updated ALTER TABLE ... SET TABLESPACE patch