Thank you.
> > This makes sense to me. I only lament the fact that this makes the
> > module a misnomer. Do we want to 1) rename the module (how
> > inconvenient), 2) create a separate module for this (surely not
> > warranted), or 3) accept it and move on?
Although I also feel uneasy with the module name, I suppose this
is not so major change as changing the module name.
> I'm not sure why this is suggested as being part of pg_freespace and
> not part of pageinspect? (Which is where all the other inspection
> tools live).
I'm afraid I wasn't aware of that. I think the following
operation shows the info of fsm.
| =# select fsm_page_contents(get_raw_page('t', 'fsm', 0));
| fsm_page_contents
| -------------------
| 0: 147 +
| 1: 147 +
...
| 2047: 147 +
| 4095: 147 +
| fp_next_slot: 0 +
If this is the only way to inspect fsm info with this module, I
can't say it is consise enough just to know the fsm info
corresponds to certain heap block. pg_freespace seems preferable
for such a purpose.
Following the manner shown above, I'll provide vm_page_contents
then command and it'll show result as following.
| =# select vm_page_contents(get_raw_page('t', 'vm', 0));
| v_page_contents
| -------------------
| 0: t +
| 1: f +
...
| 65343: t +
# Too long...
It should useful in other aspects but it seems a bit complicated
just to know about visibility bits for certain blocks.
> If I wanted to see the vismap (and I do...) then I'd like to see the
> whole vismap, not just the part that relates to blocks currently in
> cache.
> If you do want that, you can just join the two things together
> (function to see vismap joined to pg_freespace).
>From the aspect of interface, thay look to be separate
functions.
On the other hand there's no problem to add vm_page_contents to
pageinspect, although in another output format. It'll look like,
| v_page_contents
| -------------------
| 0000: 0 0 1 1 1 0 0 0 0 0 1 1 0 0 1 0 +
| 0001: 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 +
| ffff: 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 +
...
| ff30: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
# 't' and 'f' are too confusing beeing shown in a line...
Any suggestions for the output format?
> (Having said that, I don't have a major objection to it being in
> pg_freespace as well).
I prefer to leave that issue this time for anyone - including me :-p
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
