Re: BTree on-disk page ordering

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BTree on-disk page ordering
Date: 2006-05-08 23:13:52
Message-ID: 2471.1147130032@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> The mention of the changes to the btree scan code in the latest weekly
> news got me curious so I started looking at the 'executive summary'
> (read as: README) of the patch changes for both the scan patch and the
> btbulkdelete patch. If my understanding is correct, vacuum will only see
> a speed improvement when an index's on-disk storage order has a low
> correlation to index order. Is there any way to see what that
> correlation is on a running system? I'm wondering if anyone has checked
> to see what kind of performance impact a highly out-of-order index has
> on index scans.

There's nothing built in. If you feel like hacking something, I've
attached a truly ugly tool that I've used once or twice in the past to
debug broken indexes. It's got some smarts about detecting inconsistent
index structure and it looks like this latest version was meant to dump
out the index keys of a particular index. You could modify it to just
scan the level-zero pages and compute some statistics about their
ordering.

regards, tom lane

Attachment Content-Type Size
unknown_filename text/plain 8.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Albert Cervera Areny 2006-05-08 23:20:21 Inheritance, Primary Keys and Foreign Keys
Previous Message Tom Lane 2006-05-08 23:06:01 Re: performance question (something to do w/ parameterized