To: Florian Helmberger <fh@25th-floor.com>
cc: pgsql-admin@postgresql.org
Subject: Re: pg_class reltuples/relpages not updated by autovacuum/vacuum 
In-reply-to: <4DD28F73.6010108@25th-floor.com> 
References: <4DD28F73.6010108@25th-floor.com>
Comments: In-reply-to Florian Helmberger <fh@25th-floor.com>
	message dated "Tue, 17 May 2011 17:08:35 +0200"
Date: Wed, 25 May 2011 11:49:57 -0400
Message-ID: <19785.1306338597@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Florian Helmberger <fh@25th-floor.com> writes:
> I think I've pinned the problem down to the values pg_class holds for 
> the affected TOAST table:
> relpages  | 433596
> reltuples | 1868538
> These values are significantly too low. Interestingly, the autovacuum 
> logout reports the correct values:
> 	pages: 0 removed, 34788136 remain
> 	tuples: 932487 removed, 69599038 remain
> but these aren't stored in pg_class after each run.

I've moved discussion of this to pgsql-hackers, since this appears to be
an actual bug.


> Side note: while trying to debug this I've noticed, that the TOAST
> chunks on 32-bit systems have the documented size of 2000 bytes, on 
> 64-bit systems they have 1996 bytes. Is this normal/on purpose?

I don't have the exact numbers in my head, but the TOAST chunk size does
depend on a MAXALIGN calculation, so it being different between 32- and
64-bit isn't surprising.

			regards, tom lane