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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
