Re: cluster index on a table

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: cluster index on a table
Date: 2009-07-17 00:27:35
Message-ID: 407d949e0907161727v33af9a91l64195f6a86f4d0af@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Jul 17, 2009 at 1:02 AM, Scott Carey<scott(at)richrelevance(dot)com> wrote:
> Indexes would point to a heap page for normal tables and clustered index
> pages for clustered tables.  When new versions of data come in, it may point
> to new clustered index pages, just like they currently get modified to point
> to new heap pages with new data.  A split just means more data is modified.
> And if multiple versions are still 'live' they point to multiple versions --
> just as they now have to with the ordinary heap pages.  Page splitting only
> means that there might be some copies of row versions with the same tid due
> to a split, but labeling a page with a 'creation' tid to differentiate the
> pre and post split pages removes the ambiguity.  I suppose that would
> require some page locking.

None of this makes much sense to me.

If you keep the old tuples around when you split a full page where are
you going to put the new tuples you're inserting?

Also, are you clear what a tid is? It's the block number plus the
index to the tuple entry. If you split the page and move half the
tuples to the new page they'll all have different tids.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mike Ivanov 2009-07-17 01:25:45 Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
Previous Message Scott Carey 2009-07-17 00:02:18 Re: cluster index on a table