Re: a fast bloat measurement tool (was Re: Measuring relation free space) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Date
Msg-id 20150226010439.GX5169@alvh.no-ip.org
Whole thread Raw
In response to Re: a fast bloat measurement tool (was Re: Measuring relation free space)  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-hackers
Mark Kirkwood wrote:
> On 26/02/15 13:32, Simon Riggs wrote:
> >On 25 February 2015 at 23:30, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> >
> >>That said, I don't want to block this; I think it's useful. Though, perhaps
> >>it would be better as an extension instead of in contrib? I don't think it
> >>should be very version dependent?
> >
> >The whole point of this is to get it into contrib.
> >
> >It could have published it as an extension months ago.
> >
> 
> Is this intended to replace pg_freespacemap? Not trying to be overprotective
> or anything :-) but is this new extension/module better/faster/stronger/more
> accurate etc? If so then excellent! Ohth was wondering if people either a)
> didn't know about pg_freespacemap or b) consider that it is crap and won't
> use it.

It's a replacement for pgstattuple as far as I recall, not
pg_freespacemap.  The problem with pgstattuple is that it reads every
single page of the table; this fast tool skips reading pages that are
marked all-visible in the visibility map.  The disadvantage of
pg_freespacemap is that it doesn't have page data more recent than the
last vacuum, IIRC.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Next
From: Jim Nasby
Date:
Subject: Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)