Re: Table clustering idea - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Table clustering idea
Date
Msg-id 20060627163945.GJ44573@pervasive.com
Whole thread Raw
In response to Re: Table clustering idea  ("Luke Lonergan" <llonergan@greenplum.com>)
Responses Re: Table clustering idea  (Csaba Nagy <nagy@ecircle-ag.com>)
Re: Table clustering idea  ("J. Andrew Rogers" <jrogers@neopolitan.com>)
Re: Table clustering idea  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Mon, Jun 26, 2006 at 11:31:24PM -0700, Luke Lonergan wrote:
> Jim,
> 
> On 6/26/06 8:15 PM, "Jim C. Nasby" <jnasby@pervasive.com> wrote:
> 
> > On a somewhat related note, I think that it would be advantageous if the
> > FSM had a means to prefer certain pages for a given tuple over other
> > pages. This would allow for a better way to keep heap and possibly index
> > data more compacted, and it would also be a means of keeping tables
> > loosely clustered. It would also make it far easier to shrink heaps that
> > have become bloated, because the FSM could be told to favor pages at the
> > beginning of the relation.
> 
> Interesting idea - page affinity implemented using the FSM.
> 
> WRT feasibility of BTREE organized tables, I'm not sure I see the problem.
> Teradata implemented a hashing filesystem for their heap storage and I've
> always wondered about how they handle collision and chaining efficiently,
> but it's a solved problem for sure - knowing that makes the challenge that
> much easier :-)

I know there were discussions in the past, though as per usual I can't
find them in the archives. At one point I had suggested clustering not
on a row level, but on a page level, since it doesn't really matter
terribly if the tuples in a page are clustered (worst case you can scan
the entire page).

I think one of the issues might have been: how will you handle other
indexes on the table when you can no longer point them at an item (since
items will need to move to maintain an IOT).
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Yoshiyuki Asaba
Date:
Subject: Re: SO_SNDBUF size is small on win32?
Next
From: Yoshiyuki Asaba
Date:
Subject: Re: SO_SNDBUF size is small on win32?