Measuring table and index bloat - Mailing list pgsql-performance

From Greg Smith
Subject Measuring table and index bloat
Date
Msg-id Pine.GSO.4.64.0712080127420.5116@westnet.com
Whole thread Raw
Responses Re: Measuring table and index bloat
List pgsql-performance
One of those things that comes up regularly on this list in particular are
people whose performance issues relate to "bloated" tables or indexes.
What I've always found curious is that I've never seen a good way
suggested to actually measure said bloat in any useful numeric
terms--until today.

Greg Sabino Mullane just released a Nagios plug-in for PostgreSQL that you
can grab at http://bucardo.org/nagios_postgres/ , and while that is itself
nice the thing I found most remarkable is the bloat check.  The majority
of that code is an impressive bit of SQL that anyone could use even if you
have no interest in Nagios, which is why I point it out for broader
attention.  Look in check_postgres.pl for the "check_bloat" routine and
the big statement starting at the aptly labled "This was fun to write"
section.  If you pull that out of there and replace $MINPAGES and
$MINIPAGES near the end with real values, you can pop that into a
standalone query and execute it directly.  Results look something like
this (reformatting for e-mail):

schemaname | tablename | reltuples | relpages | otta  | tbloat |
public     | accounts  |   2500000 |    41667 | 40382 |    1.0 |

wastedpages | wastedbytes | wastedsize |      iname      | ituples |
        1285 |    10526720 | 10 MB      | accounts_pkey   | 2500000 |

ipages | iotta | ibloat | wastedipages | wastedibytes | wastedisize
   5594 | 35488 |    0.2 |            0 |            0 | 0 bytes

I'd be curious to hear from those of you who have struggled with this
class of problem in the past as to whether you feel this quantifies the
issue usefully.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-performance by date:

Previous
From: Ron Mayer
Date:
Subject: Re: TB-sized databases
Next
From: Alvaro Herrera
Date:
Subject: Re: Cost-Based Vacuum Delay tuning