Re: doc: explain pgstatindex fragmentation

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Frédéric Yhuel <frederic.yhuel@dalibo.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Benoit Lobréau <benoit.lobreau@dalibo.com>
Date: 2025-01-24T10:47:36Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. doc: explain pgstatindex fragmentation

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.

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

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

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com