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

Re: Measuring relation free space

From: Noah Misch <noah(at)leadboat(dot)com>
To: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, Greg Smith <greg(at)2ndquadrant(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Measuring relation free space
Date: 2012-01-14 11:26:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Jan 14, 2012 at 04:41:57AM -0500, Jaime Casanova wrote:
> pgstattuple and relation_free_space are very close in all the numbers
> except for 2 indexes pgbench_branches_pkey and pgbench_tellers_pkey;
> after a VACUUM FULL and  a REINDEX (and the difference persistence) i
> checked pgbench_tellers_pkey contents (it has only one page besides
> the metapage) and the numbers that i look at where:
> page size: 8192
> free size:  4148
> which in good romance means 50% of free space... so, answering Noah's
> question: if that difference has some meaning i can't see it but
> looking at the evidence the measure relation_free_space() is giving is
> the good one
> so, tomorrow (or ...looking at the clock... later today) i will update
> the relation_free_space() patch to accept toast tables and other kind
> of indexes and add it to the commitfest unless someone says that my
> math is wrong and somehow there is a more accurate way of getting the
> free space (which is entirely possible)

Did you see this followup[1]?  To summarize:

- pgstattuple() and relation_free_space() should emit the same number, even if
  that means improving pgstattuple() at the same time.
- relation_free_space() belongs in the pgstattuple extension, because its role
  is cheaper access to a single pgstattuple() metric.



In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-01-14 11:36:52
Subject: Re: Disabled features on Hot Standby
Previous:From: Noah MischDate: 2012-01-14 11:17:19
Subject: Re: Disabled features on Hot Standby

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