Re: pg_freespacemap question

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: alvherre(at)commandprompt(dot)com, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_freespacemap question
Date: 2006-03-07 23:24:22
Message-ID: 440E1626.7070005@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tatsuo Ishii wrote:
>>Peter Eisentraut wrote:
>>
>>>Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
>>>
>>>>test=# select * from pg_freespacemap where blockfreebytes = 0;
>>>> blockid | relfilenode | reltablespace | reldatabase | relblocknumber | blockfreebytes
>>>>---------+-------------+---------------+-------------+----------------+----------------
>>>> 25 | 2619 | 1663 | 16403 | 0 | 0
>>>> 63 | 2619 | 1663 | 16384 | 10 | 0
>>>>(2 rows)
>>>
>>>I've never heard of this thing before but is this column order supposed to make sense?
>>
>>I have another question -- why is the view showing relfilenode and
>>reltablespace? I imagine it should be showing the relation Oid instead.
>
>
> I guess that's because FSM keeps those info, not relation oid.
>
>
>>And what is this "blockid" thing?
>
>
> from README.pg_freespacemap:
>
> blockid | | Id, 1.. max_fsm_pages
>

I put that in as a bit of a sanity check - to see if the view was
picking up all the fsm pages - guess it is a bit redundant now.

> BTW, I found the answer to my question myself by reading the source
> code: if that's an index, then blockfreebytes is explicitly set to 0.
> I suggest that this should be noted in the README and in this case
> blockfreebytes is better to set to NULL, rather than 0.
>

Good points! I had not noticed this test case. Probably NULL is better
than zero.

I'll look into making these changes! (good to see people checking the
view out).

Cheers

Mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Kirkwood 2006-03-07 23:31:36 Re: pg_freespacemap question
Previous Message Tom Lane 2006-03-07 23:14:54 Merge algorithms for large numbers of "tapes"

Browse pgsql-patches by date

  From Date Subject
Next Message Mark Kirkwood 2006-03-07 23:31:36 Re: pg_freespacemap question
Previous Message Neil Conway 2006-03-07 22:54:00 variance aggregates per SQL:2003