Re: Followup Question about Vacuum from newsgroup
От | HT |
---|---|
Тема | Re: Followup Question about Vacuum from newsgroup |
Дата | |
Msg-id | atjiae$25j7$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Followup Question about Vacuum from newsgroup (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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@sss.pgh.pa.us> wrote in message news:21502.1039988725@sss.pgh.pa.us... > HT Levine <htlevine@ebates.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 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
В списке pgsql-admin по дате отправления: