Re: VACUUM produces odd freespace values
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-09-18T01:00:48Z
Lists: pgsql-hackers
Attachments
- (unnamed) (text/plain)
Bruce Momjian wrote:
> Can anyone explain why VACUUM after INSERT shows steadily decreasing
> freespace, while DELETE of the same rows does not decrease consistently?
>
> Specifically, after one row is inserted I see:
>
> SELECT pg_freespace('mvcc_demo');
> pg_freespace
> --------------
> (0,8128)
> (1 row)
>
> but after inserting two more rows and deleting those two rows, I see:
>
> SELECT pg_freespace('mvcc_demo');
> pg_freespace
> --------------
> (0,8096)
> (1 row)
>
> Seems that value should be '(0,8128)'. Is it the unused line pointers
> that are causing this?
>
> Another odd thing --- if I change the second VACUUM to VACUUM FULL I
> see:
>
> VACUUM FULL mvcc_demo;
> VACUUM
> SELECT pg_freespace('mvcc_demo');
> pg_freespace
> --------------
> (0,0)
> (1 row)
>
> There is still a row in the table, so why is there no free space
> reported? I realize after VACUUM FULL that only the last page has
> freespace --- do we assume that will be used as default for the next
> addition and just not bother with the free space map? --- makes sense if
> we do that. Does this happen because cluster creates a new relfilenode?
>
> I am attaching the init script, the SQL query script, and the results I
> obtained against our CVS HEAD.
Sorry. Attached is trimmed-down result file that shows just the
problem.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +