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. +