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 <t...@sss.pgh.pa.us> wrote: > John R Pierce <pie...@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. > > regards, tom lane > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
