Re: VACUUM produces odd freespace values

Thom Brown wrote:
> > VACUUM mvcc_demo;
> > VACUUM
> > SELECT pg_relation_size('mvcc_demo');
> > ?pg_relation_size
> > ------------------
> > ? ? ? ? ? ? ? ?0
> > (1 row)
> >
> 
> That's odd.  When I delete val 2, the freespace goes back up in 9.0rc1
> (attached).

Your numbers are odd too.  With one row after INSERT you show:
(0,8128)

but after delete you with one row left you show:
(0,8096)

You also dip to (0,8032), which I don't see.  I now see we only track
range of free space values. For example, freespace.c has:
* We use just one byte to store the amount of free space on a page, so we* divide the amount of free space a page can
haveinto 256 different* categories. The highest category, 255, represents a page with at least* MaxFSMRequestSize bytes
offree space, and the second highest category* represents the range from 254 * FSM_CAT_STEP, inclusive, to*
MaxFSMRequestSize,exclusive.** MaxFSMRequestSize depends on the architecture and BLCKSZ, but assuming* default 8k
BLCKSZ,and that MaxFSMRequestSize is 24 bytes, the categories* look like this*** Range     Category* 0    - 31   0* 32
- 63   1* ...    ...  ...* 8096 - 8127 253* 8128 - 8163 254* 8164 - 8192 255
 

So, my guess is that the unused item pointers are causing the free space
to fall into a smaller category than we had after the first INSERT.  I
bet if I pulled more columns from heap_page_items() I could see it.

Anyway, I think I have my explaination now.  Thanks.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +