Skip site navigation (1) Skip section navigation (2)

Re: Measuring relation free space

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Greg Smith <greg(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Measuring relation free space
Date: 2012-01-23 19:56:24
Message-ID: 1327348230-sup-8518@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Excerpts from Noah Misch's message of vie ene 20 22:33:30 -0300 2012:
> On Fri, Jan 20, 2012 at 07:03:22PM -0500, Jaime Casanova wrote:
> > On Wed, Jan 18, 2012 at 7:01 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > On Wed, Jan 18, 2012 at 09:46:20AM -0500, Jaime Casanova wrote:
> > >>
> > >> ignoring all non-leaf pages still gives a considerable difference
> > >> between pgstattuple and relation_free_space()
> > >
> > > pgstattuple() counts the single B-tree meta page as always-full, while
> > > relation_free_space() skips it for all purposes. ?For tiny indexes, that can
> > > shift the percentage dramatically.
> > >
> > 
> > ok, i will reformulate the question. why is fine ignoring non-leaf
> > pages but is not fine to ignore the meta page?
> 
> pgstattuple() figures the free_percent by adding up all space available to
> hold tuples and dividing that by the simple size of the relation.  Non-leaf
> pages and the meta page get identical treatment: both never hold tuples, so
> they do not contribute to the free space.

Hm.  Leaf pages hold as much tuples as non-leaf pages, no?  I mean
for each page element there's a value and a CTID.  In non-leaf those
CTIDs point to other index pages, one level down the tree; in leaf pages
they point to the heap.

The metapage is special in that it is not used to store any user data,
just a pointer to the root page.

-- 
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: A.M.Date: 2012-01-23 20:00:38
Subject: Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
Previous:From: Tom LaneDate: 2012-01-23 19:49:09
Subject: Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group