Re: doc: explain pgstatindex fragmentation

On 1/24/25 11:47, Bertrand Drouvot wrote:
> Hi Frédéric,
> 
> On Thu, Jan 23, 2025 at 10:00:27AM +0100, Frédéric Yhuel wrote:
>> On 1/22/25 12:34, Bertrand Drouvot wrote:
>>> I'm not sure it's good to describe something as the inverse of "something
>>> else". See my proposal below.
>>>
>>
>> Yeah... bloat is a more familiar concept, so I wanted to link these two
>> metrics
> 
> Yeah but in the (rare?) case "bloat" is not known then one would have to make
> sense of it first.
> 

OK let's not talk about bloat then :-)


>>> I’m not sure we need to add the extra details in a paragraph below the fields
>>> description. What about changing the fields description?
>>>
>>> Something concise enough like?
>>>
>>> avg_leaf_density: shows how full leaf pages currently are (100 if full)
>>
>> That should do :-)
> 
> Thanks!
> 

I don't know if you noticed Laurenz's suggestion, because he forgot to 
CC you, but I like it very much. I think we should mention the default 
fillfactor (90 for indexes).

>>> leaf_fragmentation: shows how much physical and logical ordering of leaf pages
>>> differ (zero if they don't)
>>>
>>
>> It looks good to me.
> 
> Thanks!
> 
>> I've noticed that maximum leaf_fragmentation can have a huge impact on a
>> range index-only scan, when reading all blocs from disks, even on my laptop
>> machine with SSD, but I don't know if this is the right place to document
>> this?
> 
> Yeah, that might be worth to mention. Maybe below the descriptions then? (keeping
> the changes above in the description).
> 

OK, thanks. I've tried to put it all together, based on v2 patch from 
Laurenz. Here is a v3 patch.

(I'm unsure who should be author or reviewer, but I guess the committer 
will fix that anyway, if the patch were to be merged).