> > Tatsuo Ishii wrote:
> >> BTW, I noticed difference of outputs from pg_freespacemap and
> >> pgstattuple.
> >>
> >> I ran pgbench and inspected "accounts" table by using these tools.
> >>
> >> pg_freespacemap:
> >> sum of bytes: 250712
> >>
> >> pgstattuple:
> >> free_space: 354880
> >>
> >> Shouldn't they be identical?
>
> No, because (a) pgbench vacuums at the start of the run not the end,
I ran VACUUM after pbench run and still got the differece.
> and (b) vacuum/fsm disregard pages with "uselessly small" amounts of
> free space (less than the average tuple size, IIRC).
That sounds strange to me. Each record of accounts tables is actually
exactly same, i.e fixed size. So it should be possible that UPDATE
reuses any free spaces made by previous UPDATE. If FSM neglects those
free spaces "because they are uselessly small", then the unrecycled
pages are getting grow even if they are regulary VACUUMed, no?
> I do notice a rather serious shortcoming of pg_freespacemap in its
> current incarnation, which is that it *only* shows you the per-page free
> space data, and not any of the information that would let you determine
> what the FSM is doing to filter the raw data. The per-relation
> avgRequest and lastPageCount fields would be interesting for instance.
> Perhaps there should be a second view with one row per relation to
> carry the appropriate data.
--
Tatsuo Ishii
SRA OSS, Inc. Japan