Re: CLUSTER not lose indexes
От | Bruce Momjian |
---|---|
Тема | Re: CLUSTER not lose indexes |
Дата | |
Msg-id | 200207052012.g65KCR215377@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: CLUSTER not lose indexes (Alvaro Herrera <alvherre@atentus.com>) |
Ответы |
Re: CLUSTER not lose indexes
|
Список | pgsql-patches |
Alvaro Herrera wrote: > > In general, I'm not thrilled about expending more code on the existing > > fundamentally-broken implementation of CLUSTER. We need to look at > > making use of the ability to write a new version of a table (or index) > > under a new relfilenode value, without changing the table's OID. > > However, some parts of your patch will probably still be needed when > > someone gets around to making that happen, so I won't object for now. OK, I remember now. In renamerel(), the new clustered file is renamed to the old table name. However, it has a new oid. The idea of relfilenode was that we want to cluster the table and keep the same relation oid. That way, other system tables that reference that OID will still work. 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. -- 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
В списке pgsql-patches по дате отправления: