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 →
-
doc: explain pgstatindex fragmentation
- 960135114629 19 (unreleased) landed
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