Skip site navigation (1) Skip section navigation (2)

Re: Table clustering idea

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Luke Lonergan <llonergan(at)greenplum(dot)com>
Cc: Dawid Kuroczko <qnex42(at)gmail(dot)com>,Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Table clustering idea
Date: 2006-06-27 16:39:45
Message-ID: 20060627163945.GJ44573@pervasive.com (view raw or flat)
Thread:
Lists: 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(at)pervasive(dot)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(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

Responses

pgsql-hackers by date

Next:From: Yoshiyuki AsabaDate: 2006-06-27 16:43:37
Subject: Re: SO_SNDBUF size is small on win32?
Previous:From: Yoshiyuki AsabaDate: 2006-06-27 16:33:48
Subject: Re: SO_SNDBUF size is small on win32?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group