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

From ITAGAKI Takahiro
Subject Re: pgstattuple extension for indexes
Date
Msg-id 20060818092409.5557.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: pgstattuple extension for indexes  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Responses Re: pgstattuple extension for indexes
List pgsql-hackers
Satoshi Nagayasu <nagayasus@nttdata.co.jp> wrote:

> Well, in that way, following two conditions,
>    [1] [x] [2] [y] [3]
> and
>    [3] [x] [2] [y] [1]
> will be calculated as same fragmentation ratio(100%), I can't agree
> with that, because both will generate different costs while index scan
> in the real world (I don't care about page splitting algorithm now).

I think the calculations (100%) are appropriate, because we should do
REINDEX in both case. Supposing to the sizes of [x], [y] are mega or giga
bytes, the order is not important; we have to do large seeks in both case.
In addition, the latter case rarely happens in real world, isn't it? 


> However, in such way, if I get '57.6%' as a fragmentation radio,
> what does it mean? What can I do next?

I think the information of fragmentations are probably not 
the most important; the information users want to know are 
"When to do REINDEX?" and "How to set the fillfactor?".

I hope you to write how to interpret the framgentation (and other) info
in README. In my understanding, I'll write "You'd better do REINDEX when
you see the fragmentation is greater than 50%" under the present
calculation method.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Going for "all green" buildfarm results
Next
From: Tom Lane
Date:
Subject: Re: Can I assume there's only one _RETURN rule?