| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
| Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, alvherre(at)commandprompt(dot)com, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: [PATCHES] pg_freespacemap question |
| Date: | 2006-03-13 00:43:11 |
| Message-ID: | 11738.1142210591@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
> 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,
and (b) vacuum/fsm disregard pages with "uselessly small" amounts of
free space (less than the average tuple size, IIRC).
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2006-03-13 01:51:24 | Re: [PATCHES] pg_freespacemap question |
| Previous Message | Mark Kirkwood | 2006-03-12 22:48:33 | Re: [PATCHES] pg_freespacemap question |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2006-03-13 01:51:24 | Re: [PATCHES] pg_freespacemap question |
| Previous Message | Mark Kirkwood | 2006-03-12 22:48:33 | Re: [PATCHES] pg_freespacemap question |