From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)atentus(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: CLUSTER not lose indexes |
Date: | 2002-07-05 05:45:09 |
Message-ID: | 200207050545.g655j9s08777@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera wrote:
> Bruce Momjian dijo:
>
> > Alvaro Herrera wrote:
> > > Hackers:
> > >
> > > I've modified commands/cluster.c so that it recreates the indexes on the
> > > table after clustering the table. I attach the patch.
>
> > I think Tom was suggesting that you may want to continue work on CLUSTER
> > and make use of relfilenode. After the cluster, you can just update
> > pg_class.relfilenode with the new file name (random oid generated at
> > build time) and as soon as you commit, all backends will start using the
> > new file and you can delete the old one.
>
> I'm looking at pg_class, and relfilenode is equal to oid in all cases
> AFAICS. If I create a new, "random" relfilenode, the equality will not
> hold. Is that OK? Also, is the new relfilenode somehow guaranteed to
Yes, they are all the same only because we haven't gotten CLUSTER fixed
yet. ;-) We knew we needed to make cases where they are not the same
specifically for cases like CLUSTER.
> not be assigned to another relation (pg_class tuple, I think)?
It will be fine. The relfilenode will be the one assigned to the new
heap table and will not be used by others.
>
>
> > In this code, we delete the old relation, then rename the new one. It
> > would be good to have this all happen in one update of
> > pg_class.relfilenode; that way it is an atomic operation.
>
> OK, I'll see if I can do that.
>
> > Let us know if you want to pursue that and we can give you additional
> > assistance. I would like to see CLUSTER really polished up. More
> > people are using it now and it really needs someone to focus on it.
>
> I thought CLUSTER was meant to be replaced by automatically clustering
> indexes. Isn't that so? Is anyone working on that?
We have no idea how to automatically cluster based on an index. Not
even sure how the commercial guys do it.
> > Glad to see you working on CLUSTER. Welcome aboard.
>
> Thank you. I'm really happy to be able to work in Postgres.
Great.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-05 06:01:00 | Re: Issues Outstanding for Point In Time Recovery (PITR) |
Previous Message | Bruce Momjian | 2002-07-05 05:42:28 | Re: Issues Outstanding for Point In Time Recovery (PITR) |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-07-05 06:28:47 | Re: CLUSTER not lose indexes |
Previous Message | Alvaro Herrera | 2002-07-05 05:34:38 | Re: CLUSTER not lose indexes |