Re: Measuring relation free space - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Measuring relation free space
Date
Msg-id 20120114112651.GB1081@tornado.leadboat.com
Whole thread Raw
In response to Re: Measuring relation free space  (Jaime Casanova <jaime@2ndquadrant.com>)
Responses Re: Measuring relation free space  (Jaime Casanova <jaime@2ndquadrant.com>)
List 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
thesame time.
 
- relation_free_space() belongs in the pgstattuple extension, because its role is cheaper access to a single
pgstattuple()metric.
 

Thanks,
nm

[1] http://archives.postgresql.org/message-id/20111218165625.GB6393@tornado.leadboat.com


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Disabled features on Hot Standby
Next
From: Simon Riggs
Date:
Subject: Re: Disabled features on Hot Standby