Re: CLUSTER TODO item

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CLUSTER TODO item
Date: 2001-10-12 03:35:30
Message-ID: Pine.LNX.4.21.0110121222430.3116-100000@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 11 Oct 2001, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-10-12 05:17:14 Re: Glitch in handling of postmaster -o options
Previous Message Hannu Krosing 2001-10-12 03:28:20 Re: optimizer question