On Thu, Dec 12, 2002 at 04:03:47PM -0800, Stephan Szabo wrote:
> On Thu, 12 Dec 2002, johnnnnnn wrote:
>
> > I think the code changes would be complicated. Just at a 30-second
> > consideration, this would need to touch:
> > - all sql (selects, inserts, updates, deletes)
> > - vacuuming
> > - indexing
> > - statistics gathering
> > - existing clustering
>
> I think his idea was to treat it similarly to the way that the
> system treats tables >2G with .N files. The only thing is that
> I believe the code that deals with that wouldn't be particularly
> easy to change to do it though, but I've only taken a cursory look at
> what I think is the place that does that(storage/smgr/md.c). Some sort of
> good partitioning system would be nice though.
I don't think this is doable without a huge amount of work. The storage
manager doesn't know anything about what is in a page, let alone a
tuple. And it shouldn't, IMHO. Upper levels don't know how are pages
organized in disk; they don't know about .1 segments and so on, and they
shouldn't.
I think this kind of partition doesn't buy too much. I would really
like to have some kind of auto-clustering, but it should be implemented
in some upper level; e.g., by leaving some empty space in pages for
future tuples, and arranging the whole heap again when it runs out of
free space somewhere. Note that this is very far from the storage
manager.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La realidad se compone de muchos sueños, todos ellos diferentes,
pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos)