Skip site navigation (1) Skip section navigation (2)

Re: Followup Question about Vacuum from newsgroup

From: "HT" <htlevine(at)ebates(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Followup Question about Vacuum from newsgroup
Date: 2002-12-16 03:46:22
Message-ID: atjiae$25j7$ (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Now here's a little more information.  I did this VACUUM on a table which
was NOT truncated.  It has many additions and updates, but very few if any
deletions.  In this case, did I have anything to gain with VACUUM?  Does the
thing about the toast files still hold?    same instructions below?   Thanks
so much!

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
> HT Levine <htlevine(at)ebates(dot)com> writes:
> > My suspicion is that there are pg_toast_xxxxx files left in the base
> > directory?    If I identify them with oid2name (waiting for netops to
> > that)    is it ok to just delete those toast files?
> No.
> In pre-7.3 releases, TRUNCATE TABLE did not automatically truncate the
> associated TOAST table, which was a nasty oversight :-(.  However, those
> releases would also allow you to manually truncate a TOAST table (which
> was also a bad oversight, but rather fortunate in hindsight).  The bad
> news is that they think TOAST tables are system tables --- so the only
> way to fully truncate a toastable table in 7.2 is
> TRUNCATE TABLE toast-table-for-foo;
> in a standalone backend started with -O option :-(
> This mess is fixed in 7.3 --- TRUNCATE automatically truncates the toast
> table along with its master, when you truncate the master.
> regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?

In response to

pgsql-admin by date

Next:From: HuubDate: 2002-12-16 08:45:38
Subject: Re: client for solaris
Previous:From: Tom LaneDate: 2002-12-15 21:45:25
Subject: Re: Followup Question about Vacuum from newsgroup

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group