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" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > HT Levine <[EMAIL PROTECTED]> 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 build > > 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; > TRUNCATE TABLE 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? > > http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
