Re: CLUSTER TODO item - Mailing list pgsql-hackers

I put some work i to this last night. Here's how it works.

1) sanity checks
2) save information (IndexInfo *) about indices on the relation being
clustered.
3) build an uncatalogued heap so that the API can be used without too much
fuss and get a new relfilenode 
(heap_create_with_catalog(...,RELKIND_UNCATALOGED,...)
4) scan the index, inserting tuples in index order into the uncatalogued
relation (ie, insert data into new relfilenode).
5) update relcache/system with new relfilenode for clustered relation
6) drop/create indices, given (2)
7) smgrunlink() old relfilenode
8) Remove uncatalogued relation from relation from relcache

There are two issues here. One is minor: At step three I should create a
new toast table entry, and then attach it to the clustered relation at
step five.

The second point is that postgres doesn't seem to like me creating
uncataloged relations and then doing RelationForgetRelation(). I will look
a little harder though.

Gavin


On Sun, 24 Feb 2002, Bruce Momjian wrote:

> 
> Gavin, please continue working on this feature and continue discussion
> the hackers list.
> 
> ---------------------------------------------------------------------------
> 
> Gavin Sherry wrote:
> > 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
> > 
> > 
> 
>