Re: CLUSTER TODO item
От | Gavin Sherry |
---|---|
Тема | Re: CLUSTER TODO item |
Дата | |
Msg-id | Pine.LNX.4.21.0110121222430.3116-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | CLUSTER TODO item (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: CLUSTER TODO item
Re: CLUSTER TODO item Re: CLUSTER TODO item |
Список | pgsql-hackers |
On Thu, 11 Oct 2001, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Can I get a status on this? > > It's not gonna happen for 7.2, I think ... > > regards, tom lane I'd love it to go out with 7.2 but I've had no time to work on this patch lately. The reason I need time is that, after having fiddled a fair bit, I've decided that there really needs to be support for the creation of a new relfilenode in the storage manager. The current patch works like this: Create new heap (heap_create()) Copy tuples from old heap to new heap via index scan Form a new pg_class tuple simple_heap_update() update catalogue indices rebuild existing indices This causes an overflow in the localbuf.c so I guess this is wrong (included in patch on 24/sep) =). I've looked at various combinations of this: memcpy() the old Relation into a new Relation, update smgrunlink() the old Relation and heap_storage_create() the new relation. This dies because smgrunlink only schedules the drop, where as heap_storage_create() actually creates a file on the file system (open() returns with EEXIST). I've also tried just copying the structure but heap_open() relies on OID not relfilenode. I'm probably going about it the wrong way, but it strikes me that there needs to be a way to abstract the relfilenode from OID in the heap access code so that one can easily manipulate the heap on disk without having to play with OIDs. I would have included code examples/clearer description but the box I don't have access to the box I created the patches on atm =(. Gavin
В списке pgsql-hackers по дате отправления: