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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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