Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems like renamerel will have to stay because it is used by ALTER TABLE
> > RENAME, so we just need some new code that updates the relfilenode of
> > the old pg_class row to point to the new clustered file. Swapping
> > relfilenodes between the old and new pg_class rows and deleting the new
> > table should do the trick of deleting the non-clustered file and the
> > temp pg_class row at the same time.
>
> I think you're still letting your thinking be contorted by the existing
> CLUSTER implementation. Do we need a temp pg_class entry at all? Seems
> like we just want to UPDATE the pg_class row with the new relfilenode
> value; then we can see the update but no one else can (till we commit).
> Ditto for the indexes.
>
> What's still a little unclear to me is how to access the old heap and
> index files to read the data while simultaneously accessing the new ones
> to write it. Much of the existing code likes to have a Relation struct
> available, not only a RelFileNode, so it may be necessary to have both
> old and new Relations present at the same time. If that's the case we
> might be stuck with making a temp pg_class entry just to support a phony
> Relation :-(
Yes, that was my conclusion, that we need the temp heap so we can access
it in a clean manner. Sure, it would be nice if we could access a file
on its own, but it doesn't seem worth the complexity required to
accomplish it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026