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.
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 |