From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CLUSTER TODO item |
Date: | 2001-09-23 21:04:34 |
Message-ID: | 17805.1001279074@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I've been looking at CLUSTER today. I've put together a patch which
>> recreates all the indices which current CLUSTER drops and copies relacl
>> from the old pg_class tuple and puts it in the new one.
This is entirely the wrong way to go at it.
> We did strange things with this in the past because we didn't have
> pg_class.relfilenode. Now that we do, you can just recreate the heap
> table using a different oid filename and update relfilenode when you are
> done.
Yes. CLUSTER should not do one single thing to the system catalogs,
except heap_update the pg_class rows for the table and indexes with
new relfilenode values. That is the facility that a rewrite of CLUSTER
was waiting for, so now that we have it, it's pointless to put more
work into the old CLUSTER implementation.
Note: I'm not convinced that relfilenode and pg_class.oid are each
used in exactly the right spots. Once we have cases where they can
differ, we may well find some bugs to flush out. But that needs to
happen anyway, so don't let it dissuade you from doing CLUSTER the
right way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2001-09-23 23:02:00 | Re: CVS changes |
Previous Message | Kevin Way | 2001-09-23 20:54:01 | Re: confounding, incorrect constraint error |