Tom,
thanks much for your help, the cluster command did the trick.
fyi running 8.1.2
On Sat, 2006-04-29 at 14:48 -0400, Tom Lane wrote:
> Warren Little <[EMAIL PROTECTED]> writes:
> > Could this be the reference to the toast table that is preventing the
> > vacuum from deleting the toast data?
Warren Little <[EMAIL PROTECTED]> writes:
> Could this be the reference to the toast table that is preventing the
> vacuum from deleting the toast data? And what purges "dropped" columns
> if not a full vacuum.
Actually, the way that toast references work is that they'll go away at
the next updat
selecting pg_attributes for the casedocument table shows
there is column with the following attributes
24216115|"pg.dropped.2"|0|0|-1|2|0|-1|-1|f|"x"|"i"|f|f|
t|t|
I also noticed a few other tables have a similar "dropped" column.
Could this be the reference to the toast table th
I am now a little confused.
I ran the following with all but localhost connections disabled
vacuumdb --full --verbose -t casedocument -d tigris > vacfull.log 2>&1
which produced the following output:
INFO: vacuuming "public.casedocument"
INFO: "casedocument": found 0 removable, 39663 nonremov
Tom,
I'll run the vacuum over the weekend and see how that goes.
And, yes, large pdf documents (4-24mb a piece).
thanks
On Fri, 2006-04-28 at 16:03 -0400, Tom Lane wrote:
> Warren Little <[EMAIL PROTECTED]> writes:
> > 3) I know that once upon a time the table had a bytea column, but that
> >
Warren Little <[EMAIL PROTECTED]> writes:
> 3) I know that once upon a time the table had a bytea column, but that
> was dropped. Do I need to do a full vacuum on that table to get rid of
> the related toast data?
Yup. (I take it it was a pretty darn bulky bytea column, too)
