Re: [PATCHES] ALTER TABLE ... SET TABLESPACE - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Date
Msg-id Pine.LNX.4.58.0406211120320.24854@linuxworld.com.au
Whole thread Raw
In response to Re: [PATCHES] ALTER TABLE ... SET TABLESPACE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] ALTER TABLE ... SET TABLESPACE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 20 Jun 2004, Tom Lane wrote:

> Gavin Sherry <swm@linuxworld.com.au> writes:
> > On Mon, 21 Jun 2004, Tatsuo Ishii wrote:
> >> Also I think we need to enhance ALTER INDEX to assign new table spaces
> >> for indexes. Assigning different tables spaces for tables and indexes
> >> are essential to gain more I/O speed IMO.
>
> > I thought about this. ALTER INDEX doesn't exist yet and I figured that,
> > unlike the case of tables, its easy to drop and recreate indexes in new
> > tablespaces.
>
> The precedents we already have (ALTER OWNER, RENAME, SET STATISTICS)
> are that ALTER TABLE applies to any relation type for which it makes
> sense.  So I'd expect ALTER TABLE SET TABLESPACE to just work on
> indexes, not that we'd go and invent an ALTER INDEX ... command.

Yes, of course.

>
> Given that you implement the data transfer as a straight block-by-block
> copy and not some kind of tuple-at-a-time thing, I would think that
> it would be trivial to consider them the same case from an
> implementation point of view, too.

But I did implement it as a tuple at a time thing. I reused the code from
rebuild_relation()...

What did you have in mind?

Gavin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] ALTER TABLE ... SET TABLESPACE