Re: cluster index on a table - Mailing list pgsql-performance

From Greg Stark
Subject Re: cluster index on a table
Date
Msg-id 407d949e0907161727v33af9a91l64195f6a86f4d0af@mail.gmail.com
Whole thread Raw
In response to Re: cluster index on a table  (Scott Carey <scott@richrelevance.com>)
Responses Re: cluster index on a table
List pgsql-performance
On Fri, Jul 17, 2009 at 1:02 AM, Scott Carey<scott@richrelevance.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

pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: cluster index on a table
Next
From: Mike Ivanov
Date:
Subject: Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1