I've isolated the problem to the json field not showing up in pg_stats, which affects the calculation of the avg row size in the bloat query.
I'm not sure if this is a json issue or some other kind of issue.
db_name=# select c.column_name, c.data_type from information_schema.columns c where table_name = 'table_name' and not exists (select 1 from pg_stats s where c.table_name = s.tablename and c.column_name = s.attname);
column_name | data_type
-------------+-----------
criteria | json
(1 row)
-G
On Tue, Oct 29, 2013 at 1:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
John R Pierce <pierce@hogranch.com> writes: > On 10/29/2013 12:41 PM, Gregory Haase wrote: >> db_name=# VACUUM FULL VERBOSE table_schema.table_name; >> INFO: vacuuming "table_schema.table_name" >> INFO: "table_name": found 2 removable, 29663 nonremovable row >> versions in 1754 pages >> DETAIL: 0 dead row versions cannot be removed yet. >> CPU 0.07s/0.10u sec elapsed 0.30 sec.
> is there an old transaction pending? that 'masks' vacuum from touching > any tuples newer than the start of that transaction.
If old transactions were the problem, vacuum would be reporting that some-large-number of dead row versions couldn't be removed yet.
There doesn't seem to be anything obviously wrong here.