Re: [PERFORM] CLUSTER command
От | Alvaro Herrera |
---|---|
Тема | Re: [PERFORM] CLUSTER command |
Дата | |
Msg-id | 20021213004719.GA19217@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: [PERFORM] CLUSTER command (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: [PERFORM] CLUSTER command
|
Список | pgsql-general |
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)
В списке pgsql-general по дате отправления: