Re: pgstattuple extension for indexes - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: pgstattuple extension for indexes
Date
Msg-id 20060817122348.GB31061@svana.org
Whole thread Raw
In response to Re: pgstattuple extension for indexes  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: pgstattuple extension for indexes
List pgsql-hackers
On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
> I think this condition should be regarded as full-fragmented,
> but pgstatindex reports that the leaf_fragmentation is 50%.
>
> Presently, fragmentation factor is computed as the code below:
>
>     if (opaque->btpo_next != P_NONE && opaque->btpo_next < blkno)
>         stat->fragments++;
>
> But the method has the above problem. So I suggest to use whether
> the right link points to the next adjacent page or not.
>
>     if (opaque->btpo_next != P_NONE && opaque->btpo_next != blkno + 1)
>         stat->fragments++;
>
> Do you think which method is better? Or do you have other ideas?

If we do it your way, then every index will probably get a
fragmentation of nearly 100%. That's not very useful. I don't agree
that your example is fully fragmented, since on the first read the OS
will read the next four (or more) blocks so all the others are
zero-cost.

A more useful definition of fragmentation would be: if you're scanning
forward through an index, how often do you have to jump backwards
again. The current calculation seems to get that fairly right...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: An Idea for planner hints
Next
From: Andrew Dunstan
Date:
Subject: Re: Enum proposal / design