Re: CLUSTER not lose indexes - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: CLUSTER not lose indexes
Date
Msg-id Pine.LNX.4.44.0207061832350.2262-100000@cm-lcon-46-187.cm.vtr.net
Whole thread Raw
In response to Re: CLUSTER not lose indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CLUSTER not lose indexes
List pgsql-patches
Tom Lane dijo:

> 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.

That's what I originally thought: mess around directly with the smgr (or
with some upper layer? I don't know) to create a new relfilenode, and
then attach it to the heap.  I don't know if it's possible or too
difficult.

Then, with Bruce's explanation, I thought I should just create a temp
table and exchange relfilenodes, which is much simpler.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"El dia que dejes de cambiar dejaras de vivir"




pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Wrap access to Oid II
Next
From: Bruce Momjian
Date:
Subject: Re: CLUSTER not lose indexes